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. Effectively, that's what devres does, it releases the resource when the device is unbound. Revocable takes care of avoiding a UAF of a subsequent access. We subsystems that invented subsystem specific implementations for a revocable mechanism for exactly those cases. For instance, there is drm_dev_enter() drm_dev_exit() and drm_dev_unplug() which ultimately does the same things as DRM specific implementation. If the resource is not a device resource, then revocable is clearly not the correct solution however.
