netdev - Re: [RFC PATCH net-next 1/4] net-sysfs: remove rtnl

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: <20250116154241.5e495e24@kernel.org>
Date: Thu, 16 Jan 2025 15:42:41 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Antoine Tenart <atenart@...nel.org>
Cc: davem@...emloft.net, pabeni@...hat.com, edumazet@...gle.com,
 netdev@...r.kernel.org, gregkh@...uxfoundation.org, mhocko@...e.com,
 stephen@...workplumber.org
Subject: Re: [RFC PATCH net-next 1/4] net-sysfs: remove rtnl_trylock from
 device attributes

On Thu, 16 Jan 2025 14:36:17 +0100 Antoine Tenart wrote:
> While refreshing the series, especially after adding the dev_isalive()
> check, I found out we actually do not need to drop the sysfs protection
> and hold a reference to the net device during the whole rtnl locking
> section. This is because after getting the rtnl lock and once we know
> the net device dismantle hasn't started yet, we're sure dismantle won't
> start (and the device won't be freed) until we give back the rtnl lock.
> 
> This makes the new helpers easier to use, does not require to expose
> the kernfs node to users, making the code more contained; but the
> locking order is not as perfect.
> 
> We would go from (version 1),
> 
> 1. unlocking sysfs
> 2. locking rtnl
> 3. unlocking rtnl
> 4. locking sysfs
> 
> to (version 2),
> 
> 1. unlocking sysfs
> 2. locking rtnl
> 3. locking sysfs
> 4. unlocking rtnl
> 
> This is actually fine because the "sysfs lock" isn't a lock but a
> refcnt, with the only deadlock situation being when draining it.
> 
> Version 1: https://github.com/atenart/linux/commit/596c5d9895ccdb75057978abd6be1a42ee4b448e
> Version 2: https://github.com/atenart/linux/commit/c6659bb26f564f1fd63d1c279616f57141e9f2bf
> 
> Thoughts? Apart from that question, either series is ready for
> submission.

Nice, yes, I think that works!