linux-kernel - Re: net: hang in unregister_netdevice: waiting for lo to become free

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7d98027d-e810-a079-49c5-0bf8beef390e@nokia.com>
Date:   Wed, 21 Feb 2018 16:53:54 +0200
From:   Tommi Rantala <tommi.t.rantala@...ia.com>
To:     Neil Horman <nhorman@...driver.com>,
        Dmitry Vyukov <dvyukov@...gle.com>
Cc:     Xin Long <lucien.xin@...il.com>, David Ahern <dsahern@...il.com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Cong Wang <xiyou.wangcong@...il.com>,
        David Miller <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Willem de Bruijn <willemb@...gle.com>,
        Jakub Kicinski <jakub.kicinski@...ronome.com>,
        Rasmus Villemoes <linux@...musvillemoes.dk>,
        netdev <netdev@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Alexey Kuznetsov <kuznet@....inr.ac.ru>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        syzkaller <syzkaller@...glegroups.com>,
        Dan Streetman <ddstreet@...onical.com>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        Alexey Kodanev <alexey.kodanev@...cle.com>,
        Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
        linux-sctp@...r.kernel.org
Subject: Re: net: hang in unregister_netdevice: waiting for lo to become free

On 20.02.2018 18:26, Neil Horman wrote:
> On Tue, Feb 20, 2018 at 09:14:41AM +0100, Dmitry Vyukov wrote:
>> On Tue, Feb 20, 2018 at 8:56 AM, Tommi Rantala
>> <tommi.t.rantala@...ia.com> wrote:
>>> On 19.02.2018 20:59, Dmitry Vyukov wrote:
>>>> Is this meant to be fixed already? I am still seeing this on the
>>>> latest upstream tree.
>>>>
>>>
>>> These two commits are in v4.16-rc1:
>>>
>>> commit 4a31a6b19f9ddf498c81f5c9b089742b7472a6f8
>>> Author: Tommi Rantala <tommi.t.rantala@...ia.com>
>>> Date:   Mon Feb 5 21:48:14 2018 +0200
>>>
>>>      sctp: fix dst refcnt leak in sctp_v4_get_dst
>>> ...
>>>      Fixes: 410f03831 ("sctp: add routing output fallback")
>>>      Fixes: 0ca50d12f ("sctp: fix src address selection if using secondary
>>> addresses")
>>>
>>>
>>> commit 957d761cf91cdbb175ad7d8f5472336a4d54dbf2
>>> Author: Alexey Kodanev <alexey.kodanev@...cle.com>
>>> Date:   Mon Feb 5 15:10:35 2018 +0300
>>>
>>>      sctp: fix dst refcnt leak in sctp_v6_get_dst()
>>> ...
>>>      Fixes: dbc2b5e9a09e ("sctp: fix src address selection if using secondary
>>> addresses for ipv6")
>>>
>>>
>>> I guess we missed something if it's still reproducible.
>>>
>>> I can check it later this week, unless someone else beat me to it.
>>
>> Hi Tommi,
>>
>> Hmmm, I can't claim that it's exactly the same bug. Perhaps it's
>> another one then. But I am still seeing these:
>>
>> [   58.799130] unregister_netdevice: waiting for lo to become free.
>> Usage count = 4
>> [   60.847138] unregister_netdevice: waiting for lo to become free.
>> Usage count = 4
>> [   62.895093] unregister_netdevice: waiting for lo to become free.
>> Usage count = 4
>> [   64.943103] unregister_netdevice: waiting for lo to become free.
>> Usage count = 4
>>
>> on upstream tree pulled ~12 hours ago.
>>
> Can you write a systemtap script to probe dev_hold, and dev_put, printing out a
> backtrace if the device name matches "lo".  That should tell us definitively if
> the problem is in the same location or not

Hi Dmitry, I tested with the reproducer and the kernel .config file that 
you sent in the first email in this thread:

With 4.16-rc2 unable to reproduce.

With 4.15-rc9 bug reproducible, and I get "unregister_netdevice: waiting 
for lo to become free. Usage count = 3"

With 4.15-rc9 and Alexey's "sctp: fix dst refcnt leak in 
sctp_v6_get_dst()" cherry-picked on top, unable to reproduce.


Is syzkaller doing something else now to trigger the bug...?
Can you still trigger the bug with the same reproducer?


Tommi