On Wed, Apr 07, 2021 at 03:17:46PM -0500, Josh Poimboeuf wrote: > On Fri, Apr 02, 2021 at 09:54:12AM +0200, Greg KH wrote: > > On Thu, Apr 01, 2021 at 11:59:25PM +0000, Luis Chamberlain wrote: > > > As for the syfs deadlock possible with drivers, this fixes it in a generic way: > > > > > > commit fac43d8025727a74f80a183cc5eb74ed902a5d14 > > > Author: Luis Chamberlain <mcgrof@xxxxxxxxxx> > > > Date: Sat Mar 27 14:58:15 2021 +0000 > > > > > > sysfs: add optional module_owner to attribute > > > > > > This is needed as otherwise the owner of the attribute > > > or group read/store might have a shared lock used on driver removal, > > > and deadlock if we race with driver removal. > > > > > > Signed-off-by: Luis Chamberlain <mcgrof@xxxxxxxxxx> > > > > No, please no. Module removal is a "best effort", if the system dies > > when it happens, that's on you. I am not willing to expend extra energy > > and maintance of core things like sysfs for stuff like this that does > > not matter in any system other than a developer's box. > > So I mentioned this on IRC, and some folks were surprised to hear that > module unloading is unsupported and is just a development aid. > > Is this stance documented anywhere? > > If we really believe this to be true, we should make rmmod taint the > kernel. My throw-away comment here seems to have gotten way more attention than it deserved, sorry about that everyone. Nothing is supported for anything here, it's all "best effort" :) And I would love a taint for rmmod, but what is that going to help out with? thanks, greg k-h
