public inbox for netdev@vger.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$(echo .)com \
    --cc=g.nault@alphalink$(echo .)fr \
    --cc=netdev-owner@vger$(echo .)kernel.org \
    --cc=netdev@vger$(echo .)kernel.org \
    --cc=xiyou.wangcong@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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