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.
>
> 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.
I will investigate the PADT message reception however since I am on 3.16
I don't have the commits for "pppoe: Use workqueue to die properly when
a PADT is received" and "pppoe: drop pppoe device in
pppoe_unbind_sock_work".
Matt
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
