From: Guillaume Nault <g.nault@alphalink.fr>
To: Matt Bennett <Matt.Bennett@alliedtelesis.co.nz>
Cc: "nuclearcat@nuclearcat.com" <nuclearcat@nuclearcat.com>,
"core@irc.lg.ua" <core@irc.lg.ua>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"davem@davemloft.net" <davem@davemloft.net>,
"paulus@samba.org" <paulus@samba.org>
Subject: Re: [PATCH net] ppp: don't override sk->sk_state in pppoe_flush_dev()
Date: Mon, 5 Oct 2015 14:24:59 +0200 [thread overview]
Message-ID: <20151005122459.GG2911@alphalink.fr> (raw)
In-Reply-To: <1444018131.14634.6.camel@mattb-dl>
On Mon, Oct 05, 2015 at 04:08:51AM +0000, Matt Bennett wrote:
> Hi, I am seeing this panic occur occasionally however I am unsure how to
> go about reproducing it. Is it enough to simply keep creating and
> tearing down the PPP interface? I can also test and/or investigate this
> issue if a suitable reproduction method is available.
>
There are at least two issues resulting in similar Oops.
The first one goes with MTU/address/link state updates on the
underlying interface: any such update on an interface used by a
PPPoE connection will generally result in an Oops when releasing the
PPPoE connection. This is fixed by e6740165b8f7 ("ppp: don't override
sk->sk_state in pppoe_flush_dev()").
The second one seems to be trickier. It looks like a race wrt. PADT
message reception. Reproducing the bug will probably require to
generate some PADT flooding to a host that creates and releases PPPoE
connections.
next prev parent reply other threads:[~2015-10-05 12:25 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-30 9:45 [PATCH net] ppp: don't override sk->sk_state in pppoe_flush_dev() Guillaume Nault
2015-10-02 8:01 ` Denys Fedoryshchenko
2015-10-02 17:54 ` Guillaume Nault
2015-10-04 16:08 ` Denys Fedoryshchenko
2015-10-05 4:08 ` Matt Bennett
2015-10-05 12:24 ` Guillaume Nault [this message]
2015-10-06 0:26 ` Matt Bennett
2015-10-06 4:46 ` Matt Bennett
2015-10-06 9:46 ` Guillaume Nault
2015-10-06 21:12 ` Matt Bennett
2015-10-07 10:32 ` Guillaume Nault
2015-10-06 8:50 ` Guillaume Nault
2015-10-05 12:08 ` Guillaume Nault
2015-10-07 12:12 ` Guillaume Nault
2015-10-13 2:13 ` Denys Fedoryshchenko
2015-10-13 7:24 ` Guillaume Nault
2015-10-22 0:14 ` Matt Bennett
2015-10-22 0:53 ` Denys Fedoryshchenko
2015-10-22 14:49 ` Guillaume Nault
2015-10-05 10:05 ` 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=20151005122459.GG2911@alphalink.fr \
--to=g.nault@alphalink.fr \
--cc=Matt.Bennett@alliedtelesis.co.nz \
--cc=core@irc.lg.ua \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=nuclearcat@nuclearcat.com \
--cc=paulus@samba.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 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.