Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1374575 > unrolled thread

Re: Kernel crash on startup - bisected to commit 3b24d854cb35

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Kernel crash on startup - bisected to commit 3b24d854cb35 Eric Dumazet <edumazet@google.com> - 2016-04-09 07:40 +0200
    Re: Kernel crash on startup - bisected to commit 3b24d854cb35 Larry Finger <Larry.Finger@lwfinger.net> - 2016-04-09 19:00 +0200
      Re: Kernel crash on startup - bisected to commit 3b24d854cb35 Kalle Valo <kvalo@codeaurora.org> - 2016-04-11 14:50 +0200

#1374575 — Re: Kernel crash on startup - bisected to commit 3b24d854cb35

On Fri, Apr 8, 2016 at 10:28 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> Following a recent pull of the wireless-drivers-next repo. my system got a
> kernel panic on startup at native_apic_msr_write+0x27. The problem was
> bisected to commit 3b24d854cb35 ("tcp/dccp: do not touch listener sk_refcnt
> under synflood"). I am confident of the bisection as a kernel built with the
> previous commit (3a5d1c0) boots OK.
>
> I have not yet captured the entire traceback for the crash, but I do have a
> crappy photo of the screen that I have attached. The RIP is at
> native_apic_msr_write+0x27. As this crash is likely configuration dependent,
> a copy of my .config is also attached. Note that IPv6 is turned off on my
> machine.
>
> Please let me know if any other info is needed.

Can you double check you have this fix ?

commit 8501786929de4616b10b8059ad97abd304a7dddf
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Apr 6 22:07:34 2016 -0700

    tcp/dccp: fix inet_reuseport_add_sock()

    David Ahern reported panics in __inet_hash() caused by my recent commit.

    The reason is inet_reuseport_add_sock() was still using
    sk_nulls_for_each_rcu() instead of sk_for_each_rcu().
    SO_REUSEPORT enabled listeners were causing an instant crash.

    While chasing this bug, I found that I forgot to clear SOCK_RCU_FREE
    flag, as it is inherited from the parent at clone time.

    Fixes: 3b24d854cb35 ("tcp/dccp: do not touch listener sk_refcnt
under synflood")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: David Ahern <dsa@cumulusnetworks.com>
    Tested-by: David Ahern <dsa@cumulusnetworks.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

[toc] | [next] | [standalone]

#1374653

On 04/09/2016 12:33 AM, Eric Dumazet wrote:
> On Fri, Apr 8, 2016 at 10:28 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
>> Following a recent pull of the wireless-drivers-next repo. my system got a
>> kernel panic on startup at native_apic_msr_write+0x27. The problem was
>> bisected to commit 3b24d854cb35 ("tcp/dccp: do not touch listener sk_refcnt
>> under synflood"). I am confident of the bisection as a kernel built with the
>> previous commit (3a5d1c0) boots OK.
>>
>> I have not yet captured the entire traceback for the crash, but I do have a
>> crappy photo of the screen that I have attached. The RIP is at
>> native_apic_msr_write+0x27. As this crash is likely configuration dependent,
>> a copy of my .config is also attached. Note that IPv6 is turned off on my
>> machine.
>>
>> Please let me know if any other info is needed.
>
> Can you double check you have this fix ?
>
> commit 8501786929de4616b10b8059ad97abd304a7dddf
> Author: Eric Dumazet <edumazet@google.com>
> Date:   Wed Apr 6 22:07:34 2016 -0700
>
>      tcp/dccp: fix inet_reuseport_add_sock()
>
>      David Ahern reported panics in __inet_hash() caused by my recent commit.
>
>      The reason is inet_reuseport_add_sock() was still using
>      sk_nulls_for_each_rcu() instead of sk_for_each_rcu().
>      SO_REUSEPORT enabled listeners were causing an instant crash.
>
>      While chasing this bug, I found that I forgot to clear SOCK_RCU_FREE
>      flag, as it is inherited from the parent at clone time.
>
>      Fixes: 3b24d854cb35 ("tcp/dccp: do not touch listener sk_refcnt
> under synflood")
>      Signed-off-by: Eric Dumazet <edumazet@google.com>
>      Reported-by: David Ahern <dsa@cumulusnetworks.com>
>      Tested-by: David Ahern <dsa@cumulusnetworks.com>
>      Signed-off-by: David S. Miller <davem@davemloft.net>

No, I did not have that patch. After pulling from net-next to get it, my system 
no longer panics.

Note to linux-wireless readers. At the moment, a system built from 
wireless-drivers-next will have this problem.

Thanks,

Larry

[toc] | [prev] | [next] | [standalone]

#1375790

Larry Finger <Larry.Finger@lwfinger.net> writes:

>> Can you double check you have this fix ?
>>
>> commit 8501786929de4616b10b8059ad97abd304a7dddf
>> Author: Eric Dumazet <edumazet@google.com>
>> Date:   Wed Apr 6 22:07:34 2016 -0700
>>
>>      tcp/dccp: fix inet_reuseport_add_sock()
>>
>>      David Ahern reported panics in __inet_hash() caused by my recent commit.
>>
>>      The reason is inet_reuseport_add_sock() was still using
>>      sk_nulls_for_each_rcu() instead of sk_for_each_rcu().
>>      SO_REUSEPORT enabled listeners were causing an instant crash.
>>
>>      While chasing this bug, I found that I forgot to clear SOCK_RCU_FREE
>>      flag, as it is inherited from the parent at clone time.
>>
>>      Fixes: 3b24d854cb35 ("tcp/dccp: do not touch listener sk_refcnt
>> under synflood")
>>      Signed-off-by: Eric Dumazet <edumazet@google.com>
>>      Reported-by: David Ahern <dsa@cumulusnetworks.com>
>>      Tested-by: David Ahern <dsa@cumulusnetworks.com>
>>      Signed-off-by: David S. Miller <davem@davemloft.net>
>
> No, I did not have that patch. After pulling from net-next to get it,
> my system no longer panics.
>
> Note to linux-wireless readers. At the moment, a system built from
> wireless-drivers-next will have this problem.

I'm currently writing a pull request to Dave and once he pulls it I'll
fast forward wireless-drivers-next to latest net-next. Usually this take
two days or so.

-- 
Kalle Valo

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web