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:

quoted

On Mon Jan 26, 2026 at 1:07 AM CET, Jason Gunthorpe wrote:

quoted

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.

quoted

quoted

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