Revocable references vs. krefs

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

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.