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
