Revocable references vs. krefs

Posted Sep 27, 2025 7:53 UTC (Sat) by farnz (subscriber, #17727)
In reply to: Revocable references vs. krefs by Alan.Stern
Parent article: Revocable references for transient devices

I can't see anything in krefs that requires someone who's done a kref_get to register for notification that the underlying hardware is actually gone, nor is there anything that bounds the time between the hardware going away and the kref_put. With revocable references, that's implicit in the fact that, once the reference is revoked, you can't get access ever again.

That, in turn, makes a huge difference at code review time; you literally cannot forget to register with the device driver for notification that the hardware's gone away, because it's implicit in the design of revocable references.

Revocable references vs. krefs

Posted Sep 27, 2025 15:47 UTC (Sat) by Alan.Stern (subscriber, #12437) [Link] (3 responses)

You are correct that nothing bounds the time interval between device removal and the final kref_put(). As I mentioned above, this should not be considered a problem because the data structures being pinned by the kref generally don't occupy a lot of memory. (Although I admit there is always the possibility of missing puts causing a memory leak.)

Nevertheless, what you say leaves a strong impression that revocable references are best suited for scenarios other than registration of hot-removable devices. With removable devices, the subsystem to which the device is registered will keep its reference until the device is unregistered, and it will expect to be able to use the device whenever it wants, up until that time. It's not that the subsystem registers with the device driver for notifications; it's the other way around: The driver registers and unregisters the device with the subsystem. This does not pose any problems for code review, because reviewers always expect to see drivers both registering and unregistering their devices -- that is the accepted pattern and a reviewer would definitely notice if it weren't being followed.

All right, given that revocable references aren't well suited for registering removable devices with subsystems, then what are the intended use cases for revocable references?

Revocable references vs. krefs

Posted Sep 29, 2025 9:10 UTC (Mon) by farnz (subscriber, #17727) [Link] (2 responses)

The use case is where you have something claiming a removable device, like a PPP driver (for example); in other words, where the subsystem registers with the removable device, rather than the normal way round.

You want the subsystem to stop doing work that depends on the removable device being present as quickly as possible - there is no point spending lots of compute on building a new PPP frame to send, or a new work item to pass across to the GPU, if the underlying hardware is gone. Instead, you want it to error out early and stop wasting time doing things that it's going to submit to a driver that's already deregistered from the subsystem.

Revocable references vs. krefs

Posted Sep 29, 2025 13:55 UTC (Mon) by Alan.Stern (subscriber, #12437) [Link] (1 responses)

Okay, that makes sense. Jon's original article did not draw any distinction between a subsystem claiming a removable device and the device's driver registering with a subsystem.

Revocable references vs. krefs

Posted Sep 30, 2025 0:50 UTC (Tue) by riking (subscriber, #95706) [Link]

Of course, for the subsystems that the removable device's driver does register with, it *cannot* process those unregistrations until it is satisfied that its consumers have stopped trying to use the device (now, via struct revokable). Once the SRCU critical section has passed, the subsystem deregistrations can happen.