netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matt Bennett <Matt.Bennett@alliedtelesis.co.nz>
To: "g.nault@alphalink.fr" <g.nault@alphalink.fr>
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 00:26:20 +0000	[thread overview]
Message-ID: <1444091180.1468.17.camel@mattb-dl> (raw)
In-Reply-To: <20151005122459.GG2911@alphalink.fr>

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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


  reply	other threads:[~2015-10-06  0:26 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 [this message]
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=1444091180.1468.17.camel@mattb-dl \
    --to=matt.bennett@alliedtelesis.co.nz \
    --cc=core@irc.lg.ua \
    --cc=davem@davemloft.net \
    --cc=g.nault@alphalink.fr \
    --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).