From: Guillaume Nault <g.nault@alphalink.fr>
To: Matt Bennett <Matt.Bennett@alliedtelesis.co.nz>
Cc: "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>,
"nuclearcat@nuclearcat.com" <nuclearcat@nuclearcat.com>
Subject: Re: [PATCH net] ppp: don't override sk->sk_state in pppoe_flush_dev()
Date: Tue, 6 Oct 2015 10:50:36 +0200 [thread overview]
Message-ID: <20151006085036.GC2882@alphalink.fr> (raw)
In-Reply-To: <1444091180.1468.17.camel@mattb-dl>
On Tue, Oct 06, 2015 at 12:26:20AM +0000, Matt Bennett wrote:
> On Mon, 2015-10-05 at 14:24 +0200, Guillaume Nault wrote:
> > 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()").
>
> Without your patch ("ppp: don't override sk->sk_state in
> pppoe_flush_dev()") I can see the following function calls being made
> when changing the mtu on the underlying ethernet interface for the PPPoE
> connection:
>
> 1. pppoe_flush_dev() - setting PPPOX_ZOMBIE
>
> 2. pppoe_connect - setting PPPOX_NONE (shown below)
>
> /* Delete the old binding */
> if (stage_session(po->pppoe_pa.sid)) {
> pppox_unbind_sock(sk);
> pn = pppoe_pernet(sock_net(sk));
> delete_item(pn, po->pppoe_pa.sid,
> po->pppoe_pa.remote, po->pppoe_ifindex);
> if (po->pppoe_dev) {
> dev_put(po->pppoe_dev);
> po->pppoe_dev = NULL;
> }
>
> memset(sk_pppox(po) + 1, 0,
> sizeof(struct pppox_sock) - sizeof(struct sock));
> sk->sk_state = PPPOX_NONE;
> }
>
> 3. pppoe_release - No oops (since sk->sk_state is no longer in
> {PPPOX_CONNECTED,PPPOX_BOUND,PPPOX_ZOMBIE})
>
> It doesn't look to me like the above functions can execute
> asynchronously but I'd have to look harder. I am using 3.16 by the way.
>
Just drop the pppoe_connect() call. Right after the pppoe_flush_dev()
call, sk_state is PPPOX_ZOMBIE and pppoe_dev is NULL. This is enouhg to
make pppoe_release() crash.
The typical scenario e6740165b8f7 ("ppp: don't override sk->sk_state in
pppoe_flush_dev()") fixes is:
Userspace process #1: Userspace process #2:
--------------------- ---------------------
fd = socket(AF_PPPOX, PX_PROTO_OE, 0);
connect(fd, {AF_PPPOX, PX_PROTO_EO,
$sid, $mac_addr, $ifname},
sizeof(struct sockaddr_pppox));
... process_packets() ... # ip link set $ifname mtu $mtu
close(fd); --> Kernel Oops
next prev parent reply other threads:[~2015-10-06 8:50 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
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 [this message]
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=20151006085036.GC2882@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).