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 for Android: free password hash cracker in your pocket

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

Date: Wed, 18 Oct 2023 11:15:47 -0700
From: Stephen Hemminger <stephen@...workplumber.org>
To: Antoine Tenart <atenart@...nel.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

On Wed, 18 Oct 2023 17:47:42 +0200
Antoine Tenart <atenart@...nel.org> wrote:

> Some time ago we tried to improve the rtnl_trylock/restart_syscall
> situation[1]. What happens is when there is rtnl contention, userspace
> accessing net sysfs attributes will spin and experience delays. This can
> happen in different situations, when sysfs attributes are accessed
> (networking daemon, configuration, monitoring) while operations under
> rtnl are performed (veth creation, driver configuration, etc). A few
> improvements can be done in userspace to ease things, like using the
> netlink interface instead, or polling less (or more selectively) the
> attributes; but in the end the root cause is always there and this keeps
> happening from time to time.

What attribute is not exposed by netlink, and only by sysfs?
There will always be more overhead using sysfs.
That doesn't mean the locking should not be fixed, just that better
to avoid the situation if possible.