From: Nick Bowler <nbowler@elliptictech.com>
To: "Timo Teräs" <timo.teras@iki.fi>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>
Subject: Re: Occasional oops with IPSec and IPv6.
Date: Mon, 21 Nov 2011 10:12:42 -0500 [thread overview]
Message-ID: <20111121151242.GA29494@elliptictech.com> (raw)
In-Reply-To: <4EC75C99.4000304@iki.fi>
On 2011-11-19 09:36 +0200, Timo Teräs wrote:
> On 11/18/2011 11:21 PM, Nick Bowler wrote:
> > On 2011-11-18 22:06 +0200, Timo Teräs wrote:
> >> Alternatively, we could just run the "slow path" unconditionally with
> >> the test load to see if it fixes the issue. At least that'd be pretty
> >> good test if it's a problem in the ipv6 fragmentation code or something
> >> else.
> >
> > Good call. I replaced the "correct geometry" check with an
> > unconditional "goto slow_path_clean;", and I can no longer reproduce the
> > crash. So at the very least, I have a workaround now. (I still have
> > Herbert Xu's six patches applied on top of Linus' master).
>
> Ok, so it's most likely ipv6 code issue then. My change just happened to
> trigger it.
>
> > I then tried the smaller change above, but this does not correct the
> > issue.
>
> That's not it then (likely).
>
> I did notice that the headroom of the main skb is never checked. So my
> other suggestion is to try something like:
>
> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
> index 1c9bf8b..735c4dc 100644
> --- a/net/ipv6/ip6_output.c
> +++ b/net/ipv6/ip6_output.c
> @@ -668,7 +668,8 @@ int ip6_fragment(struct sk_buff *skb, int
> (*output)(struct sk_buff *))
>
> if (first_len - hlen > mtu ||
> ((first_len - hlen) & 7) ||
> - skb_cloned(skb))
> + skb_cloned(skb) ||
> + skb_headroom(skb) < sizeof(struct frag_hdr))
> goto slow_path;
>
> skb_walk_frags(skb, frag) {
Tried this (still on top of Herbert Xu's patch set) to no avail; the
crash still occurs :(.
Using the unconditional slow path workaround, I ran the test over the
weekend and it did not crash, so that seems to be stable.
> Other than that, I hope some of the ipv6 people could take a look at it.
> But the problem is that somewhere some headroom check isn't taking
> place, or is checking for too little of headroom.
Thanks,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
prev parent reply other threads:[~2011-11-21 15:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-17 19:09 Occasional oops with IPSec and IPv6 Nick Bowler
2011-11-18 16:27 ` Nick Bowler
2011-11-18 16:39 ` Eric Dumazet
2011-11-18 18:27 ` Timo Teräs
2011-11-18 19:26 ` Nick Bowler
2011-11-18 20:06 ` Timo Teräs
2011-11-18 20:10 ` David Miller
2011-11-18 21:21 ` Nick Bowler
2011-11-19 7:36 ` Timo Teräs
2011-11-21 15:12 ` Nick Bowler [this message]
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=20111121151242.GA29494@elliptictech.com \
--to=nbowler@elliptictech.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=timo.teras@iki.fi \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.