Re: [PATCH v7 0/3] drivers/base: Introduce revocable

[Jason Gunthorpe <jgg@nvidia.com>]

On Fri, Jan 16, 2026 at 05:16:58PM +0100, Danilo Krummrich wrote:
> On Fri Jan 16, 2026 at 5:04 PM CET, Laurent Pinchart wrote:
> > The revocable mechanism isn't the right solution for races between device
> > removal and userspace access.
> 
> I think you have to differenciate, as it depends on the resource:
> 
> If the resource is a device resource (e.g. MMIO resource regions) that must not
> be held by the driver after its bound device has been unbound, you have to
> revoke the resource from the driver, i.e. you can't just fix it with a reference
> count.

The C code doesn't really work like that, it works on sync teardown
flows. If you want to write correct C code you need to think about all
the concurrency the driver has and ensure that removal undoes it

I think Laurent is referring to the lack of a sync unregister for
fops.

In this series patches 13-16 are all fops related callbacks.

#17 kind of looks like a cancel_work_sync() is missing (ie what is
preventing this work func from running after the module unloads?)

#19 is all sysfs stuff, and sysfs already has a sync unregister, so
maybe these SRCU's can never fail?

Jason