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
| ||
|
Message-ID: <169770320930.433869.5743241833039124669@kwain> Date: Thu, 19 Oct 2023 10:13:29 +0200 From: Antoine Tenart <atenart@...nel.org> To: Greg KH <gregkh@...uxfoundation.org> Cc: davem@...emloft.net, kuba@...nel.org, pabeni@...hat.com, edumazet@...gle.com, netdev@...r.kernel.org, mhocko@...e.com, stephen@...workplumber.org Subject: Re: [RFC PATCH net-next 1/4] net-sysfs: remove rtnl_trylock from device attributes Quoting Greg KH (2023-10-18 18:49:18) > On Wed, Oct 18, 2023 at 05:47:43PM +0200, Antoine Tenart wrote: > > +static inline struct kernfs_node *sysfs_rtnl_lock(struct kobject *kobj, > > + struct attribute *attr, > > + struct net_device *ndev) > > +{ > > + struct kernfs_node *kn; > > + > > + /* First, we hold a reference to the net device we might use in the > > + * locking section as the unregistration path might run in parallel. > > + * This will ensure the net device won't be freed before we return. > > + */ > > + dev_hold(ndev); > > + /* sysfs_break_active_protection was introduced to allow self-removal of > > + * devices and their associated sysfs files by bailing out of the > > + * sysfs/kernfs protection. We do this here to allow the unregistration > > + * path to complete in parallel. The following takes a reference on the > > + * kobject and the kernfs_node being accessed. > > + * > > + * This works because we hold a reference onto the net device and the > > + * unregistration path will wait for us eventually in netdev_run_todo > > + * (outside an rtnl lock section). > > + */ > > + kn = sysfs_break_active_protection(kobj, attr); > > + WARN_ON_ONCE(!kn); > > If this triggers, you will end up rebooting the machines that set > panic-on-warn, do you mean to do that? And note, the huge majority of > Linux systems in the world have that enabled, so be careful. Right. My understanding was this can not happen here and I added this one as a "that should not happen and something is really wrong", as the attribute should be valid until at least the call to sysfs_break_active_protection. Thanks, Antoine
Powered by blists - more mailing lists