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..

> > 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()

Jason

Reply via email to