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:

quoted

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