All of lore.kernel.org
 help / color / mirror / Atom feed
From: Timo Teras <timo.teras@iki.fi>
To: Pravin Shelar <pshelar@nicira.com>
Cc: netdev@vger.kernel.org
Subject: Re: GRE+XFRM+GSO crashes
Date: Wed, 22 May 2013 14:09:48 +0300	[thread overview]
Message-ID: <20130522140948.3e3ad94e@vostro> (raw)
In-Reply-To: <CALnjE+qOf2pxzP0-7s4AsSNDbG5M5s8bXFDqYoD-5NgmtKYixA@mail.gmail.com>

On Tue, 21 May 2013 15:32:35 -0700
Pravin Shelar <pshelar@nicira.com> wrote:

> On Tue, May 21, 2013 at 1:01 AM, Timo Teras <timo.teras@iki.fi> wrote:
> > On Mon, 20 May 2013 10:58:03 -0700
> > Pravin Shelar <pshelar@nicira.com> wrote:
> >
> >> On Sun, May 19, 2013 at 11:41 PM, Timo Teras <timo.teras@iki.fi>
> >> wrote:
> >> > Since upgrade from 3.8 to 3.9 I've started getting the below
> >> > mentioned BUG crashes. One of the few relevant changes seems to
> >> > be GSO support in GRE driver.
> >> >
> >> > Turning off SG (and GSO) seems to make these crashes disappear.
> >> >
> >> > The basic setup is:
> >> > - gre1 is an NBMA tunnel (no explicit destination, nor bound
> >> >   target interface; opennhrp daemon creates neigh mappings)
> >> > - IPsec policy to encrypt all GRE traffic in transport mode
> >> > - VIA Padlock hardware for AES acceleration
> >> > - GRE traffic goes to r8169 NIC; rx on, gro on, tx off, sg off,
> >> > gso off
> >> >
> >> > Incidentally, when I tried exact same setup ran as virtualized, I
> >> > was unable to reproduce this crash. I suspect it depends on the
> >> > target NIC acceleration capabilities.
> >> >
> >> I do not have access to this hardware, can you tell me what are
> >> target device capabilities?
> >
> > The physical hardware from which the OOPS is from:
> >[snip]
> 
> OK. I am still not able to reproduce it, Can you try attached patch?
> if that works, I will send out proper patch.

No. Seems this is not GSO related at all, after all. I was unable to
reliably reproduce this oops originally and for some weird reason it
happened only with GSO and this specific hardware. I finally
pinpointed a way to trigger this reliably, and it does happen without
GSO too.

I'm pretty sure I've pinpointed the commit breaking things, and have a
fix already building. Will post it after testing.

Thanks for the help anyways.

      parent reply	other threads:[~2013-05-22 11:08 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-20  6:41 GRE+XFRM+GSO crashes Timo Teras
2013-05-20 17:58 ` Pravin Shelar
2013-05-21  8:01   ` Timo Teras
2013-05-21 22:32     ` Pravin Shelar
2013-05-21 22:46       ` Eric Dumazet
2013-05-22  4:56         ` Pravin Shelar
2013-05-22 11:09       ` Timo Teras [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=20130522140948.3e3ad94e@vostro \
    --to=timo.teras@iki.fi \
    --cc=netdev@vger.kernel.org \
    --cc=pshelar@nicira.com \
    /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.