All of lore.kernel.org
 help / color / mirror / Atom feed
From: Denys Fedoryshchenko <nuclearcat@nuclearcat.com>
To: Guillaume Nault <g.nault@alphalink.fr>
Cc: Cong Wang <xiyou.wangcong@gmail.com>,
	Linux Kernel Network Developers <netdev@vger.kernel.org>,
	netdev-owner@vger.kernel.org
Subject: Re: ppp/pppoe, still panic 4.15.3 in ppp_push
Date: Sat, 03 Mar 2018 11:33:53 +0200	[thread overview]
Message-ID: <25907ffa1ae57576327746acee07956f@nuclearcat.com> (raw)
In-Reply-To: <20180302174328.GD1413@alphalink.fr>

On 2018-03-02 19:43, Guillaume Nault wrote:
> On Thu, Mar 01, 2018 at 10:07:05PM +0200, Denys Fedoryshchenko wrote:
>> On 2018-03-01 22:01, Guillaume Nault wrote:
>> > diff --git a/drivers/net/ppp/ppp_generic.c
>> > b/drivers/net/ppp/ppp_generic.c
>> > index 255a5def56e9..2acf4b0eabd1 100644
>> > --- a/drivers/net/ppp/ppp_generic.c
>> > +++ b/drivers/net/ppp/ppp_generic.c
>> > @@ -3161,6 +3161,15 @@ ppp_connect_channel(struct channel *pch, int
>> > unit)
>> >  		goto outl;
>> >
>> >  	ppp_lock(ppp);
>> > +	spin_lock_bh(&pch->downl);
>> > +	if (!pch->chan) {
>> > +		/* Don't connect unregistered channels */
>> > +		ppp_unlock(ppp);
>> > +		spin_unlock_bh(&pch->downl);
> 
> This is obviously wrong. It should have been
> +		spin_unlock_bh(&pch->downl);
> +		ppp_unlock(ppp);
> 
> Sorry, I shouldn't have hurried.
> This is fixed in the official version.
> 
>> > +		ret = -ENOTCONN;
>> > +		goto outl;
>> > +	}
>> > +	spin_unlock_bh(&pch->downl);
>> >  	if (pch->file.hdrlen > ppp->file.hdrlen)
>> >  		ppp->file.hdrlen = pch->file.hdrlen;
>> >  	hdrlen = pch->file.hdrlen + 2;	/* for protocol bytes */
>> Ok, i will try to test that at night.
>> Thanks a lot! For me also problem solved anyway by removing 
>> unit-cache, just
>> i think it's nice to have bug fixed :)
>> 
> I think this bug has been there forever, indeed it's good to have it 
> fixed.
> Thanks a lot for your help (and patience!).
> 
> FYI, if you see accel-ppp logs like
> "ioctl(PPPIOCCONNECT): Transport endpoint is not connected", then that
> means the patch prevented the scenario that was leading to the original
> crash.
> 
> Out of curiosity, did unit-cache really bring performance improvements
> on your workload?
On old kernels it definitely did, due local specifics (electricity 
outages) i might have few thousands of interfaces deleted and created 
again in short period of time.
And before interfaces creation/deletion (especially when there is 
thousands of them) was very expensive.

  reply	other threads:[~2018-03-03  9:33 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-14 13:17 ppp/pppoe, still panic 4.15.3 in ppp_push Denys Fedoryshchenko
2018-02-14 16:07 ` Guillaume Nault
2018-02-14 16:29   ` Denys Fedoryshchenko
2018-02-14 16:47     ` Guillaume Nault
2018-02-14 16:49       ` Denys Fedoryshchenko
2018-02-14 17:25         ` Guillaume Nault
2018-02-15 10:19           ` Denys Fedoryshchenko
2018-02-15 15:55             ` Guillaume Nault
2018-02-15 16:01               ` Denys Fedoryshchenko
2018-02-15 19:31                 ` Guillaume Nault
2018-02-15 19:34                   ` Denys Fedoryshchenko
2018-02-15 19:42                     ` Guillaume Nault
2018-02-16 11:13                       ` Denys Fedoryshchenko
2018-02-16 18:48                         ` Guillaume Nault
2018-02-18 10:01                           ` Denys Fedoryshchenko
2018-02-21 18:38                             ` Guillaume Nault
2018-02-20  9:05                           ` Denys Fedoryshchenko
2018-02-21 10:26                           ` Denys Fedoryshchenko
2018-02-21 18:55                             ` Guillaume Nault
2018-02-21 19:30                               ` Denys Fedoryshchenko
2018-02-21 20:04                   ` Cong Wang
2018-02-22 18:30                     ` Guillaume Nault
2018-02-22 18:51                       ` Denys Fedoryshchenko
2018-02-23  9:38                         ` Guillaume Nault
2018-02-23  9:41                           ` Denys Fedoryshchenko
2018-02-23 10:07                             ` Guillaume Nault
2018-02-23 10:54                               ` Denys Fedoryshchenko
2018-02-24 21:22                               ` Denys Fedoryshchenko
2018-02-27 10:58                               ` Denys Fedoryshchenko
2018-02-27 18:56                                 ` Guillaume Nault
2018-03-01 20:01                                   ` Guillaume Nault
2018-03-01 20:07                                     ` Denys Fedoryshchenko
2018-03-02 17:43                                       ` Guillaume Nault
2018-03-03  9:33                                         ` Denys Fedoryshchenko [this message]
2018-03-05 17:22                                           ` Guillaume Nault
2018-02-27 18:54                       ` Guillaume Nault
2018-02-15 19:20         ` Guillaume Nault

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=25907ffa1ae57576327746acee07956f@nuclearcat.com \
    --to=nuclearcat@nuclearcat.com \
    --cc=g.nault@alphalink.fr \
    --cc=netdev-owner@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=xiyou.wangcong@gmail.com \
    /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.