On Mon, Jan 26, 2026 at 01:07:20PM -0400, Jason Gunthorpe wrote: > On Mon, Jan 26, 2026 at 05:08:20PM +0100, Danilo Krummrich wrote: > > On Mon Jan 26, 2026 at 1:07 AM CET, Jason Gunthorpe wrote: > > > That's the whole issue with DRM right there - allowing driver code to > > > run after the driver has unregistered from the subsystem is > > > *dangerous* and creates all these bugs. > > > > Unfortunately, it is necessary (at least to a certain extend) in DRM. I > > think > > there is space for improvements, but I don't think we can get rid of this > > entirely, especially on the KMS side AFAIK. > > From what I saw alot of the issue with DRM was how it works the fops, > instead of the core subsytem managing the fops and calling the driver, > the driver managed its own fops and called back to the core. > > Sure, the issues may be very hard to fix in existing code, but I find > it hard to swallow the idea that a subsystem couldn't own all the > fops/etc and guard every driver callback with a lock to generate the > right kind of fence..
I also don't see a real technical reason. Retrofitting the right solution in all existing drivers wouldn't be for the faint-hearted though, so I understand the appeal for subsystems of a quick and easy suboptimal implementation. > > > IMHO since rust has the Device<Bound> stuff the revocable should have used > > > rwsem, because the expectation should be that the majority uses access, > > > not > > > try_access. > > > > Yes, the majority of uses is access(), not try_access(); not sure if rwsem > > is > > the better solution though. > > rwsem is much faster on destroy and somewhat slower on read. Which > sounds to match the use case here. Ie you wouldn't need to do special > effort to bundle the synchronize_srcu() -- Regards, Laurent Pinchart
