From: "Timo Teräs" <timo.teras@iki•fi>
To: Eric Dumazet <eric.dumazet@gmail•com>
Cc: Nick Bowler <nbowler@elliptictech•com>,
netdev@vger•kernel.org, "David S. Miller" <davem@davemloft•net>
Subject: Re: Occasional oops with IPSec and IPv6.
Date: Fri, 18 Nov 2011 20:27:26 +0200 [thread overview]
Message-ID: <4EC6A38E.6060404@iki.fi> (raw)
In-Reply-To: <1321634378.3277.35.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On 11/18/2011 06:39 PM, Eric Dumazet wrote:
> Le vendredi 18 novembre 2011 à 11:27 -0500, Nick Bowler a écrit :
>> On 2011-11-17 14:09 -0500, Nick Bowler wrote:
>>> One of the tests we do with IPsec involves sending and receiving UDP
>>> datagrams of all sizes from 1 to N bytes, where N is much larger than
>>> the MTU. In this particular instance, the MTU is 1500 bytes and N is
>>> 10000 bytes. This test works fine with IPv4, but I'm getting an
>>> occasional oops on Linus' master with IPv6 (output at end of email). We
>>> also run the same test where N is less than the MTU, and it does not
>>> trigger this issue. The resulting fallout seems to eventually lock up
>>> the box (although it continues to work for a little while afterwards).
>>>
>>> The issue appears timing related, and it doesn't always occur. This
>>> probably also explains why I've not seen this issue before now, as we
>>> recently upgraded all our lab systems to machines from this century
>>> (with newfangled dual core processors). This also makes it somewhat
>>> hard to reproduce, but I can trigger it pretty reliably by running 'yes'
>>> in an ssh session (which doesn't use IPsec) while running the test:
>>> it'll usually trigger in 2 or 3 runs. The choice of cipher suite
>>> appears to be irrelevant.
>>>
>>> I built a relatively old kernel (2.6.34) and could not reproduce the
>>> issue there, so I ran a git bisect. It pointed to the following, which
>>> (unsurprisingly) no longer reverts cleanly.
>>>
>>> Let me know if you need any more info. I'll see if I can reproduce the
>>> issue with a smaller test case...
>>
>> OK, here's a somewhat straigthforward way to reproduce it that I've
>> found. It uses a short test program called "udp_burst" which simply
>> transmits a bunch of UDP datagrams at all sizes between 1 and 10000,
>> included at the end of this mail.
>>[snip]
>
> Please note commit 80c802f307 added a known bug, fixed in commit
> 0b150932197b (xfrm: avoid possible oopse in xfrm_alloc_dst)
>
> Given commit 80c802f307 complexity, we can assume other bugs are to be
> fixed as well.
>
> Unfortunately, Timo seems unresponsive.
This looks quite different. And I've been trying to figure out what
causes this. However, the OOPS happens at ip6_fragment(), indicating
that there was not enough allocated headroom (skb underrun). My initial
thought is ipv6 bug that just got uncovered by my commit; especially
since ipv4 side is happy. But I haven't yet been able to figure this one
out.
Could you also try Herbert's latest patch set:
[0/6] Replace LL_ALLOCATED_SPACE to allow needed_headroom adjustment
This changes how the headroom is calculated, and *might* fix this issue
too if it's caused by the same SMP race condition which got uncovered by
my other commit earlier.
- Timo
next prev parent reply other threads:[~2011-11-18 18:27 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 [this message]
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
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=4EC6A38E.6060404@iki.fi \
--to=timo.teras@iki$(echo .)fi \
--cc=davem@davemloft$(echo .)net \
--cc=eric.dumazet@gmail$(echo .)com \
--cc=nbowler@elliptictech$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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