On Tue, Oct 19, 2021 at 07:28:35PM +0200, Greg KH wrote: > On Tue, Oct 19, 2021 at 09:30:05AM -0700, Luis Chamberlain wrote: > > On Tue, Oct 19, 2021 at 06:25:18PM +0200, Greg KH wrote: > > > On Tue, Oct 19, 2021 at 08:50:24AM -0700, Luis Chamberlain wrote: > > > > So do you want to take the position: > > > > > > > > Hey driver authors: you cannot use any shared lock on module removal and > > > > on sysfs ops? > > > > > > Yes, I would not recommend using such a lock at all. sysfs operations > > > happen on a per-device basis, so you can lock the device structure. > > > > All devices are going to be removed on module removal and so cannot be locked. > > devices are not normally created by a driver, that is up to the bus > controller logic. A module will just disconnect itself from the device, > the device does not go away. > > But yes, there are exceptions, and if you are doing something odd like > that, then you need to be aware of crazy things like this, so be > careful. But for all normal drivers, they do not have to worry about > this. "Recommend" is a weak position to take given a possible deadlock with sysfs. Do we want to at the very least document this is not a supported scheme? If so I can also add a simple 1 level indirrection coccinelle patch to detect these schemes and complain about them as wel, if we are going to take this position. But to simply disregard this as "not an issue", or we won't do anything seems pretty counter productive given we *do* had drivers with this issue before *and* still have them upstream, and can end up with more drivers like this later. Luis
