Searched hist:65532 (Results 1 - 8 of 8) sorted by relevance
| /linux-master/drivers/scsi/ | ||
| H A D | zorro_esp.c | diff 02f7e9f3 Tue Nov 12 10:55:23 MST 2019 Kars de Jong <jongk@linux-m68k.org> scsi: zorro_esp: Limit DMA transfers to 65536 bytes (except on Fastlane) When using this driver on a Blizzard 1260, there were failures whenever DMA transfers from the SCSI bus to memory of 65535 bytes were followed by a DMA transfer of 1 byte. This caused the byte at offset 65535 to be overwritten with 0xff. The Blizzard hardware can't handle single byte DMA transfers. Besides this issue, limiting the DMA length to something that is not a multiple of the page size is very inefficient on most file systems. It seems this limit was chosen because the DMA transfer counter of the ESP by default is 16 bits wide, thus limiting the length to 65535 bytes. However, the value 0 means 65536 bytes, which is handled by the ESP and the Blizzard just fine. It is also the default maximum used by esp_scsi when drivers don't provide their own dma_length_limit() function. The limit of 65536 bytes can be used by all boards except the Fastlane. The old driver used a limit of 65532 bytes (0xfffc), which is reintroduced in this patch. Fixes: b7ded0e8b0d1 ("scsi: zorro_esp: Limit DMA transfers to 65535 bytes") Link: https://lore.kernel.org/r/20191112175523.23145-1-jongk@linux-m68k.org Signed-off-by: Kars de Jong <jongk@linux-m68k.org> Reviewed-by: Finn Thain <fthain@telegraphics.com.au> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> |
| /linux-master/drivers/spi/ | ||
| H A D | spi-bcm2835.c | diff 8b7bd10e Sat Apr 13 12:24:14 MDT 2019 Meghana Madhyastha <meghana.madhyastha@gmail.com> spi/spi-bcm2835: Split transfers that exceed DLEN Split spi transfers into chunks of <=65532 to enable the driver to perform DMA transfer on big buffers. The DLEN register specifies the number of bytes to transfer in DMA mode. It is 16-bit wide and thus the maximum DMA transfer is 65535 bytes. Set the maximum to 65532 (4 byte aligned) since the FIFO in DMA mode is accessed in 4 byte chunks. ->max_dma_len is the value the spi core uses when splitting the buffer into scatter gather entries. The BCM2835 DMA block has 2 types of channels/engines: - Normal: Max length: 1G - Lite: Max length: 65535 Even when using a Lite channel we will not exceed the max length, so let's drop setting ->max_dma_len. Signed-off-by: Meghana Madhyastha <meghana.madhyastha@gmail.com> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Mark Brown <broonie@kernel.org> diff 8b7bd10e Sat Apr 13 12:24:14 MDT 2019 Meghana Madhyastha <meghana.madhyastha@gmail.com> spi/spi-bcm2835: Split transfers that exceed DLEN Split spi transfers into chunks of <=65532 to enable the driver to perform DMA transfer on big buffers. The DLEN register specifies the number of bytes to transfer in DMA mode. It is 16-bit wide and thus the maximum DMA transfer is 65535 bytes. Set the maximum to 65532 (4 byte aligned) since the FIFO in DMA mode is accessed in 4 byte chunks. ->max_dma_len is the value the spi core uses when splitting the buffer into scatter gather entries. The BCM2835 DMA block has 2 types of channels/engines: - Normal: Max length: 1G - Lite: Max length: 65535 Even when using a Lite channel we will not exceed the max length, so let's drop setting ->max_dma_len. Signed-off-by: Meghana Madhyastha <meghana.madhyastha@gmail.com> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Mark Brown <broonie@kernel.org> |
| H A D | spi.c | diff b59a7ca1 Tue Sep 08 09:11:29 MDT 2020 Gustav Wiklander <gustavwi@axis.com> spi: Fix memory leak on splited transfers In the prepare_message callback the bus driver has the opportunity to split a transfer into smaller chunks. spi_map_msg is done after prepare_message. Function spi_res_release releases the splited transfers in the message. Therefore spi_res_release should be called after spi_map_msg. The previous try at this was commit c9ba7a16d0f1 which released the splited transfers after spi_finalize_current_message had been called. This introduced a race since the message struct could be out of scope because the spi_sync call got completed. Fixes this leak on spi bus driver spi-bcm2835.c when transfer size is greater than 65532: Kmemleak: sg_alloc_table+0x28/0xc8 spi_map_buf+0xa4/0x300 __spi_pump_messages+0x370/0x748 __spi_sync+0x1d4/0x270 spi_sync+0x34/0x58 spi_test_execute_msg+0x60/0x340 [spi_loopback_test] spi_test_run_iter+0x548/0x578 [spi_loopback_test] spi_test_run_test+0x94/0x140 [spi_loopback_test] spi_test_run_tests+0x150/0x180 [spi_loopback_test] spi_loopback_test_probe+0x50/0xd0 [spi_loopback_test] spi_drv_probe+0x84/0xe0 Signed-off-by: Gustav Wiklander <gustavwi@axis.com> Link: https://lore.kernel.org/r/20200908151129.15915-1-gustav.wiklander@axis.com Signed-off-by: Mark Brown <broonie@kernel.org> |
| /linux-master/arch/arm/net/ | ||
| H A D | bpf_jit_32.c | diff b18bea2a Thu Jul 12 14:50:56 MDT 2018 Russell King <rmk+kernel@armlinux.org.uk> ARM: net: bpf: improve 64-bit ALU implementation Improbe the 64-bit ALU implementation from: movw r8, #65532 movt r8, #65535 movw r9, #65535 movt r9, #65535 ldr r7, [fp, #-44] adds r7, r7, r8 str r7, [fp, #-44] ldr r7, [fp, #-40] adc r7, r7, r9 str r7, [fp, #-40] to: movw r8, #65532 movt r8, #65535 movw r9, #65535 movt r9, #65535 ldrd r6, [fp, #-44] adds r6, r6, r8 adc r7, r7, r9 strd r6, [fp, #-44] Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> diff b18bea2a Thu Jul 12 14:50:56 MDT 2018 Russell King <rmk+kernel@armlinux.org.uk> ARM: net: bpf: improve 64-bit ALU implementation Improbe the 64-bit ALU implementation from: movw r8, #65532 movt r8, #65535 movw r9, #65535 movt r9, #65535 ldr r7, [fp, #-44] adds r7, r7, r8 str r7, [fp, #-44] ldr r7, [fp, #-40] adc r7, r7, r9 str r7, [fp, #-40] to: movw r8, #65532 movt r8, #65535 movw r9, #65535 movt r9, #65535 ldrd r6, [fp, #-44] adds r6, r6, r8 adc r7, r7, r9 strd r6, [fp, #-44] Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> |
| /linux-master/net/sctp/ | ||
| H A D | transport.c | diff 3822a5ff Fri Mar 18 21:17:20 MDT 2016 Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> sctp: align MTU to a word SCTP is a protocol that is aligned to a word (4 bytes). Thus using bare MTU can sometimes return values that are not aligned, like for loopback, which is 65536 but ipv4_mtu() limits that to 65535. This mis-alignment will cause the last non-aligned bytes to never be used and can cause issues with congestion control. So it's better to just consider a lower MTU and keep congestion control calcs saner as they are based on PMTU. Same applies to icmp frag needed messages, which is also fixed by this patch. One other effect of this is the inability to send MTU-sized packet without queueing or fragmentation and without hitting Nagle. As the check performed at sctp_packet_can_append_data(): if (chunk->skb->len + q->out_qlen >= transport->pathmtu - packet->overhead) /* Enough data queued to fill a packet */ return SCTP_XMIT_OK; with the above example of MTU, if there are no other messages queued, one cannot send a packet that just fits one packet (65532 bytes) and without causing DATA chunk fragmentation or a delay. v2: - Added WORD_TRUNC macro Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> |
| H A D | input.c | diff 3822a5ff Fri Mar 18 21:17:20 MDT 2016 Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> sctp: align MTU to a word SCTP is a protocol that is aligned to a word (4 bytes). Thus using bare MTU can sometimes return values that are not aligned, like for loopback, which is 65536 but ipv4_mtu() limits that to 65535. This mis-alignment will cause the last non-aligned bytes to never be used and can cause issues with congestion control. So it's better to just consider a lower MTU and keep congestion control calcs saner as they are based on PMTU. Same applies to icmp frag needed messages, which is also fixed by this patch. One other effect of this is the inability to send MTU-sized packet without queueing or fragmentation and without hitting Nagle. As the check performed at sctp_packet_can_append_data(): if (chunk->skb->len + q->out_qlen >= transport->pathmtu - packet->overhead) /* Enough data queued to fill a packet */ return SCTP_XMIT_OK; with the above example of MTU, if there are no other messages queued, one cannot send a packet that just fits one packet (65532 bytes) and without causing DATA chunk fragmentation or a delay. v2: - Added WORD_TRUNC macro Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> |
| H A D | associola.c | diff 3822a5ff Fri Mar 18 21:17:20 MDT 2016 Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> sctp: align MTU to a word SCTP is a protocol that is aligned to a word (4 bytes). Thus using bare MTU can sometimes return values that are not aligned, like for loopback, which is 65536 but ipv4_mtu() limits that to 65535. This mis-alignment will cause the last non-aligned bytes to never be used and can cause issues with congestion control. So it's better to just consider a lower MTU and keep congestion control calcs saner as they are based on PMTU. Same applies to icmp frag needed messages, which is also fixed by this patch. One other effect of this is the inability to send MTU-sized packet without queueing or fragmentation and without hitting Nagle. As the check performed at sctp_packet_can_append_data(): if (chunk->skb->len + q->out_qlen >= transport->pathmtu - packet->overhead) /* Enough data queued to fill a packet */ return SCTP_XMIT_OK; with the above example of MTU, if there are no other messages queued, one cannot send a packet that just fits one packet (65532 bytes) and without causing DATA chunk fragmentation or a delay. v2: - Added WORD_TRUNC macro Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> |
| /linux-master/include/net/sctp/ | ||
| H A D | sctp.h | diff 3822a5ff Fri Mar 18 21:17:20 MDT 2016 Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> sctp: align MTU to a word SCTP is a protocol that is aligned to a word (4 bytes). Thus using bare MTU can sometimes return values that are not aligned, like for loopback, which is 65536 but ipv4_mtu() limits that to 65535. This mis-alignment will cause the last non-aligned bytes to never be used and can cause issues with congestion control. So it's better to just consider a lower MTU and keep congestion control calcs saner as they are based on PMTU. Same applies to icmp frag needed messages, which is also fixed by this patch. One other effect of this is the inability to send MTU-sized packet without queueing or fragmentation and without hitting Nagle. As the check performed at sctp_packet_can_append_data(): if (chunk->skb->len + q->out_qlen >= transport->pathmtu - packet->overhead) /* Enough data queued to fill a packet */ return SCTP_XMIT_OK; with the above example of MTU, if there are no other messages queued, one cannot send a packet that just fits one packet (65532 bytes) and without causing DATA chunk fragmentation or a delay. v2: - Added WORD_TRUNC macro Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> |
Completed in 457 milliseconds