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: <169770164786.433869.13558540630519879540@kwain>
Date: Thu, 19 Oct 2023 09:47:27 +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 20:15:47)
> 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?

I think there were a few last time (a while a go) I checked, but it's
not an issue IMHO, if one is missing in netlink we can add it.

> That doesn't mean the locking should not be fixed, just that better
> to avoid the situation if possible.

100% agree on this one. I believe using netlink is the right way.

Having said that, sysfs is still there and (quite some time ago) while
having discussions with different projects, some were keen to switch to
netlink, but some weren't and pushed back because "sysfs is a stable
API" and "if there is a kernel issue it should be fixed in the kernel".
Not blaming anyone really, they'd have to support the two interfaces for
compatibility. My point is, yes, I would encourage everyone to use
netlink too, but we don't control every user and it's not like sysfs
will disappear anytime soon.

Thanks,
Antoine

Powered by blists - more mailing lists