netdev - Re: [RFC PATCH net-next 0/4] net-sysfs: remove rtnl_trylock/restart

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: <169764686602.6041.3041045279733408955@kwain>
Date: Wed, 18 Oct 2023 18:34:26 +0200
From: Antoine Tenart <atenart@...nel.org>
To: Stephen Hemminger <stephen@...workplumber.org>
Cc: davem@...emloft.net, kuba@...nel.org, pabeni@...hat.com, edumazet@...gle.com, netdev@...r.kernel.org, gregkh@...uxfoundation.org, mhocko@...e.com
Subject: Re: [RFC PATCH net-next 0/4] net-sysfs: remove rtnl_trylock/restart_syscall use

Quoting Stephen Hemminger (2023-10-18 17:57:17)
> The trylock was introduced to deal with lock inversion.
> It is not clear how this more complex solution prevents that.

Anything specifically in the patch 1 comments is not clear that I can
improve?

The dead lock happens between rtnl_lock and the refcounting on the
attribute kn->active, specifically when unregistering net devices
because device_del kernfs_drain will wait for the kn->active refcount to
reach KN_DEACTIVATED_BIAS, under an rtnl section. The current solution
was making one path to bail out (trylock/restart syscall).

The idea here is we can actually bail out of the attribute kn protection
(kn->active), while still letting unregistering net devices to wait for
the current sysfs operations to complete, by using the net device
refcount instead. To simplify, instead of waiting on kn->active in the
net device unregistration step, this waits on the net device refcount
(netdev_wait_allrefs_any), which is done outside an rtnl section. This
way kernfs_drain can complete under its rtnl section even if a call to
rtnl_lock is waiting in a sysfs operation.

Antoine