Searched hist:59104 (Results 1 - 2 of 2) sorted by relevance
/linux-master/include/linux/platform_data/ | ||
H A D | shmob_drm.h | diff 59104f23 Wed Jul 25 20:37:49 MDT 2018 Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> drm: shmobile: convert to SPDX identifiers Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> |
/linux-master/net/ipv4/ | ||
H A D | ip_output.c | diff 33f99dc7 Tue Jun 21 19:04:37 MDT 2011 Steffen Klassert <steffen.klassert@secunet.com> ipv4: Fix packet size calculation in __ip_append_data Git commit 59104f06 (ip: take care of last fragment in ip_append_data) added a check to see if we exceed the mtu when we add trailer_len. However, the mtu is already subtracted by the trailer length when the xfrm transfomation bundles are set up. So IPsec packets with mtu size get fragmented, or if the DF bit is set the packets will not be send even though they match the mtu perfectly fine. This patch actually reverts commit 59104f06. Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by: David S. Miller <davem@davemloft.net> diff 33f99dc7 Tue Jun 21 19:04:37 MDT 2011 Steffen Klassert <steffen.klassert@secunet.com> ipv4: Fix packet size calculation in __ip_append_data Git commit 59104f06 (ip: take care of last fragment in ip_append_data) added a check to see if we exceed the mtu when we add trailer_len. However, the mtu is already subtracted by the trailer length when the xfrm transfomation bundles are set up. So IPsec packets with mtu size get fragmented, or if the DF bit is set the packets will not be send even though they match the mtu perfectly fine. This patch actually reverts commit 59104f06. Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by: David S. Miller <davem@davemloft.net> diff 59104f06 Mon Sep 20 14:16:27 MDT 2010 Eric Dumazet <eric.dumazet@gmail.com> ip: take care of last fragment in ip_append_data While investigating a bit, I found ip_fragment() slow path was taken because ip_append_data() provides following layout for a send(MTU + N*(MTU - 20)) syscall : - one skb with 1500 (mtu) bytes - N fragments of 1480 (mtu-20) bytes (before adding IP header) last fragment gets 17 bytes of trail data because of following bit: if (datalen == length + fraggap) alloclen += rt->dst.trailer_len; Then esp4 adds 16 bytes of data (while trailer_len is 17... hmm... another bug ?) In ip_fragment(), we notice last fragment is too big (1496 + 20) > mtu, so we take slow path, building another skb chain. In order to avoid taking slow path, we should correct ip_append_data() to make sure last fragment has real trail space, under mtu... Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> |
Completed in 207 milliseconds