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 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.