linux-kernel - Re: unregister_netdevice: waiting for DEV to become free (2)

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: <3bf46fd2-1b7b-c380-a588-eadfd521ce19@gmail.com>
Date:   Mon, 22 Apr 2019 09:09:30 -0700
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     David Ahern <dsahern@...il.com>,
        Stephen Suryaputra <ssuryaextr@...il.com>
Cc:     Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
        Julian Anastasov <ja@....bg>,
        Cong Wang <xiyou.wangcong@...il.com>,
        syzbot <syzbot+30209ea299c09d8785c9@...kaller.appspotmail.com>,
        ddstreet@...e.org, dvyukov@...gle.com,
        linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
        syzkaller-bugs@...glegroups.com
Subject: Re: unregister_netdevice: waiting for DEV to become free (2)



On 04/22/2019 09:04 AM, Eric Dumazet wrote:
> 
> 
> On 04/22/2019 07:58 AM, David Ahern wrote:
>> On 4/21/19 2:41 PM, Stephen Suryaputra wrote:
>>> Hi David,
>>>
>>> I looked at patchwork. This patch hasn't been accepted. Is there a plan
>>> to resubmit? It is very useful. I had to debug refcnt issues multiple
>>> times for my employer.
>>
>> I think the inlined versions of dev_put and dev_hold are better for
>> performance.

However I do not really see dev_put()/dev_hold() being in very hot code paths.


>>
>> I could submit it with a DEBUG config to enable. It has been invaluable
>> to me over the past 3+ years debugging refcount problems.
>>
> 
> Sounds a good plan to me :)
> 

Another idea would be to track of all dev_hold(), by allocating an unique cookie
and providing the cookie at the corresponding dev_put()

The cookie would also keep track of the stack trace.

This would allow for an automatic finding of the missing release, but at extra cost of course.

This infrastructure would of course being a debug option at kernel build.