From: Eric Dumazet <eric.dumazet@gmail.com>
To: Nick Bowler <nbowler@elliptictech.com>
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
"David S. Miller" <davem@davemloft.net>
Subject: [PATCH] ip : take care of last fragment in ip_append_data
Date: Tue, 21 Sep 2010 08:16:27 +0200 [thread overview]
Message-ID: <1285049787.2323.797.camel@edumazet-laptop> (raw)
In-Reply-To: <1285018272.2323.243.camel@edumazet-laptop>
Le lundi 20 septembre 2010 à 23:31 +0200, Eric Dumazet a écrit :
> OK, I found a bug in ip_fragment() and ip6_fragment()
>
> In case slow_path is hit, we have a truesize mismatch
>
> Could you try following patch ?
>
> Thanks !
>
> [PATCH] ip : fix truesize mismatch in ip fragmentation
>
> We should not set frag->destructor to sock_wkfree() until we are sure we
> dont hit slow path in ip_fragment(). Or we risk uncharging
> frag->truesize twice, and in the end, having negative socket
> sk_wmem_alloc counter, or even freeing socket sooner than expected.
>
> Many thanks to Nick Bowler, who provided a very clean bug report and
> test programs.
>
> While Nick bisection pointed to commit 2b85a34e911bf483 (net: No more
> expensive sock_hold()/sock_put() on each tx), underlying bug is older.
>
> Reported-and-bisected-by: Nick Bowler <nbowler@elliptictech.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
> net/ipv4/ip_output.c | 8 ++++----
> net/ipv6/ip6_output.c | 10 +++++-----
> 2 files changed, 9 insertions(+), 9 deletions(-)
This previous patch works for me. I also cooked following fix, to not
enter slow path on some lengthes (MTU + N*(MTU-20))
[PATCH] 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>
---
net/ipv4/ip_output.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index 04b6989..dfd9a0d 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -927,16 +927,19 @@ alloc_new_skb:
!(rt->dst.dev->features&NETIF_F_SG))
alloclen = mtu;
else
- alloclen = datalen + fragheaderlen;
+ alloclen = fraglen;
/* The last fragment gets additional space at tail.
* Note, with MSG_MORE we overallocate on fragments,
* because we have no idea what fragment will be
* the last.
*/
- if (datalen == length + fraggap)
+ if (datalen == length + fraggap) {
alloclen += rt->dst.trailer_len;
-
+ /* make sure mtu is not reached */
+ if (datalen > mtu - fragheaderlen - rt->dst.trailer_len)
+ datalen -= ALIGN(rt->dst.trailer_len, 8);
+ }
if (transhdrlen) {
skb = sock_alloc_send_skb(sk,
alloclen + hh_len + 15,
next prev parent reply other threads:[~2010-09-21 6:16 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-20 17:44 Regression, bisected: reference leak with IPSec since ~2.6.31 Nick Bowler
2010-09-20 18:20 ` Eric Dumazet
2010-09-20 19:52 ` Nick Bowler
2010-09-20 20:00 ` David Miller
2010-09-20 21:23 ` Nick Bowler
2010-09-20 20:17 ` Eric Dumazet
2010-09-20 21:31 ` Eric Dumazet
2010-09-21 6:16 ` Eric Dumazet [this message]
2010-09-21 23:38 ` [PATCH] ip : take care of last fragment in ip_append_data David Miller
2010-09-22 4:44 ` Eric Dumazet
2010-09-22 4:53 ` David Miller
2010-09-24 21:42 ` David Miller
2010-09-21 9:12 ` Regression, bisected: reference leak with IPSec since ~2.6.31 Jarek Poplawski
2010-09-21 9:21 ` Eric Dumazet
2010-09-21 9:38 ` Jarek Poplawski
2010-09-21 9:55 ` Eric Dumazet
2010-09-21 10:07 ` Eric Dumazet
2010-09-21 10:48 ` Jarek Poplawski
2010-09-21 11:58 ` Eric Dumazet
2010-09-21 12:39 ` Jarek Poplawski
2010-09-21 14:05 ` Nick Bowler
2010-09-21 14:16 ` [PATCH] ip : fix truesize mismatch in ip fragmentation Eric Dumazet
2010-09-21 15:58 ` [PATCH v3] ip: " Eric Dumazet
2010-09-21 16:26 ` Henrique de Moraes Holschuh
2010-09-21 16:31 ` Eric Dumazet
2010-09-21 18:09 ` Henrique de Moraes Holschuh
2010-09-21 19:24 ` David Miller
2010-09-21 23:06 ` Henrique de Moraes Holschuh
2010-09-21 17:50 ` Jarek Poplawski
2010-09-21 18:47 ` Eric Dumazet
2010-09-21 19:21 ` Jarek Poplawski
2010-09-21 22:15 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1285049787.2323.797.camel@edumazet-laptop \
--to=eric.dumazet@gmail.com \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=nbowler@elliptictech.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox