On Thu, Oct 22, 2015 at 03:53:33AM +0300, Denys Fedoryshchenko wrote:
> On 2015-10-22 03:14, Matt Bennett wrote:
> >On Tue, 2015-10-13 at 05:13 +0300, Denys Fedoryshchenko wrote:
> >>On 2015-10-07 15:12, Guillaume Nault wrote:
> >>> diff --git a/drivers/net/ppp/pppoe.c b/drivers/net/ppp/pppoe.c
> >
On 2015-10-22 03:14, Matt Bennett wrote:
On Tue, 2015-10-13 at 05:13 +0300, Denys Fedoryshchenko wrote:
On 2015-10-07 15:12, Guillaume Nault wrote:
> On Mon, Oct 05, 2015 at 02:08:44PM +0200, Guillaume Nault wrote:
>>if (po) {
>>struct sock *sk = sk_pppox(po);
>>
>> -
On Tue, 2015-10-13 at 05:13 +0300, Denys Fedoryshchenko wrote:
> On 2015-10-07 15:12, Guillaume Nault wrote:
> > On Mon, Oct 05, 2015 at 02:08:44PM +0200, Guillaume Nault wrote:
> >>if (po) {
> >>struct sock *sk = sk_pppox(po);
> >>
> >> - bh_lock_sock(sk);
> >> -
> >> -
On Tue, Oct 13, 2015 at 05:13:54AM +0300, Denys Fedoryshchenko wrote:
> On 2015-10-07 15:12, Guillaume Nault wrote:
> >On Mon, Oct 05, 2015 at 02:08:44PM +0200, Guillaume Nault wrote:
> >>if (po) {
> >>struct sock *sk = sk_pppox(po);
> >>
> >>- bh_lock_sock(sk);
> >>-
> >>
On 2015-10-07 15:12, Guillaume Nault wrote:
On Mon, Oct 05, 2015 at 02:08:44PM +0200, Guillaume Nault wrote:
if (po) {
struct sock *sk = sk_pppox(po);
- bh_lock_sock(sk);
-
- /* If the user has locked the socket, just ignore
-*
On Mon, Oct 05, 2015 at 02:08:44PM +0200, Guillaume Nault wrote:
> if (po) {
> struct sock *sk = sk_pppox(po);
>
> - bh_lock_sock(sk);
> -
> - /* If the user has locked the socket, just ignore
> - * the packet. With the way two rcv protoco
On Tue, Oct 06, 2015 at 09:12:18PM +, Matt Bennett wrote:
> On Tue, 2015-10-06 at 11:46 +0200, Guillaume Nault wrote:
> > On Tue, Oct 06, 2015 at 04:46:04AM +, Matt Bennett wrote:
> > > I don't know why the code isn't like the following anyway.
> > >
> > > -if (sk->sk_state & (PPPOX_CONNEC
On Tue, 2015-10-06 at 11:46 +0200, Guillaume Nault wrote:
> On Tue, Oct 06, 2015 at 04:46:04AM +, Matt Bennett wrote:
> > > > 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 fl
On Tue, Oct 06, 2015 at 04:46:04AM +, Matt Bennett wrote:
> > > 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
On Tue, Oct 06, 2015 at 12:26:20AM +, Matt Bennett wrote:
> On Mon, 2015-10-05 at 14:24 +0200, Guillaume Nault wrote:
> > On Mon, Oct 05, 2015 at 04:08:51AM +, Matt Bennett wrote:
> > > Hi, I am seeing this panic occur occasionally however I am unsure how to
> > > go about reproducing it. I
> > 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.
Ok I think I can see the potential race here, specifically the PADT
On Mon, 2015-10-05 at 14:24 +0200, Guillaume Nault wrote:
> On Mon, Oct 05, 2015 at 04:08:51AM +, 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 inter
On Mon, Oct 05, 2015 at 04:08:51AM +, 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 suitabl
> I am doing just "dirty" patch like this, i cannot certainly remember if i
> was doing git reversal, because
> it was a while when i spotted this bug. After that pppoe server is not
> rebooting.
>
> diff -Naur linux-4.2.2-vanilla/drivers/net/ppp/pppoe.c
> linux-4.2.2-changed/drivers/net/ppp/pppoe
From: Guillaume Nault
Date: Wed, 30 Sep 2015 11:45:33 +0200
> Since commit 2b018d57ff18 ("pppoe: drop PPPOX_ZOMBIEs in pppoe_release"),
> pppoe_release() calls dev_put(po->pppoe_dev) if sk is in the
> PPPOX_ZOMBIE state. But pppoe_flush_dev() can set sk->sk_state to
> PPPOX_ZOMBIE _and_ reset po-
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.
On Sun, 2015-10-04 at 19:08 +0300
On 2015-10-02 20:54, Guillaume Nault wrote:
On Fri, Oct 02, 2015 at 11:01:45AM +0300, Denys Fedoryshchenko wrote:
Here is similar panic after patch applied (it might be different bug),
got
over netconsole:
[126348.617115] CPU: 0 PID: 5254 Comm: accel-pppd Not tainted
4.2.2-build-0087 #2
[126
On Fri, Oct 02, 2015 at 11:01:45AM +0300, Denys Fedoryshchenko wrote:
> Here is similar panic after patch applied (it might be different bug), got
> over netconsole:
>
> [126348.617115] CPU: 0 PID: 5254 Comm: accel-pppd Not tainted
> 4.2.2-build-0087 #2
> [126348.617632] Hardware name: Intel Cor
Here is similar panic after patch applied (it might be different bug),
got over netconsole:
[126348.610996] BUG: unable to handle kernel
NULL pointer dereference
at 0428
[126348.611656] IP:
[] pppoe_release+0x56/0x142 [pppoe]
[126348.612033] PGD 17d0b03067
PUD 17c721b067
PMD
Since commit 2b018d57ff18 ("pppoe: drop PPPOX_ZOMBIEs in pppoe_release"),
pppoe_release() calls dev_put(po->pppoe_dev) if sk is in the
PPPOX_ZOMBIE state. But pppoe_flush_dev() can set sk->sk_state to
PPPOX_ZOMBIE _and_ reset po->pppoe_dev to NULL. This leads to the
following oops:
[ 570.140800]
20 matches
Mail list logo
