On Wed, Jul 28, 2021 at 08:28:11AM +0000, David Laight wrote: > ... > > sysfs files are safe to use try_module_get() because once they are > > active a removal of the file cannot happen, and so removal will wait. > > I doubt it. But that is what happens. > If the module_remove() function removes sysfs nodes then (something > like) this has to happen. > > 1) rmmod (or similar) tries to remove the module. > 2) The reference count is zero so the remove is allowed. > 3) Something tries to access a sysfs node in the module. > 3a) If sysfs knew the nodes were in a module it could use > try_module_get() to ensure the module wasn't being unloaded. > Failure would cause the sysfs access to fail. > But I'm not sure it does, It does, if a sysfs file had a try_module_get() it would fail as the module is going. > and in any case it doesn't help. Not clear how from your example. > 3b) The sysfs thread calls into the module code and waits on a mutex. If try_module_get() is used on the syfs files, the deadlock is escaped if used on remove. > 3c) The rmmod thread gets around to calling into sysfs to remove the nodes. > > At this point we hit the standard 'deregistering a callback' issue. > Exactly the same issue affects removal of per-device sysfs node > from a driver's .remove function. > > Typically this is solved by making the deregister routing sleep > until all the callbacks have completed. > > So this would require functions like sysfs_remove_group() and > hwmon_device_unregister() to be allowed to sleep Both can. Both kernfs_find_and_get_ns() and kernfs_remove_by_name_ns() call mutex_lock(), they certainly can sleep. hwmon_device_unregister() calls device_del() which also holds a mutex. > and not be > called with any locks (of any kind) held that the callback > functions acquire. Not sure why you think this is a requirement. > The module reference count is irrelevant. To be clear, there were concerns that there were races here which would make things murky on sysfs operations and module removal (null deferences when accessing back the gendisk->private_data) however a a new selftest driver for sysfs [0], and error injections to allow us to test and verify all these things I just said are true. If you'd like to extend the tests to include something you might be concerned about and want to try, please send me a patch against my tree [1]. [0] https://lkml.kernel.org/r/20210703004632.621662-1-mcgrof@xxxxxxxxxx [1] https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux-next.git/log/?h=20210701-sysfs-fix-races-v2 Luis
