LWN: Comments on "Revocable references for transient devices"

Revocable references vs. krefs

riking — Tue, 30 Sep 2025 00:50:09 +0000

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.

Revocable references vs. krefs

Alan.Stern — Mon, 29 Sep 2025 13:55:06 +0000

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

farnz — Mon, 29 Sep 2025 09:10:57 +0000

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

Alan.Stern — Sat, 27 Sep 2025 15:47:41 +0000

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

farnz — Sat, 27 Sep 2025 07:53:28 +0000

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

Alan.Stern — Fri, 26 Sep 2025 14:54:07 +0000

This sounds more like a disadvantage. With krefs you _don't_ have to check every time you want to access the data structure, which certainly is easier. Instead, the owner of the data structure has to tell you (usually by making some sort of unregistration function call, which has to be made anyway) when the hardware is gone.

From your description, it seems like the other main difference is that with revocable references the data structure can usually be deallocated quite soon after the hardware goes away (delayed only by the length of an SRCU read-side critical section), whereas with krefs the data structure has to hang around for as long as anybody keeps a reference to it. This doesn't sound like a big deal, since the amount of memory used by these data structures tends not to be very large.

Overall my impression is that revocable references are somewhat harder to use than krefs with no compensating advantages.

Revocable references vs. krefs

farnz — Fri, 26 Sep 2025 11:13:34 +0000

The difference to krefs is in intention. With krefs, you've got a data structure, and you are expected to keep it alive for as long as you want it, releasing it when you're finally finished with it. Revocable references work slightly differently; you're being given the right to claim a reference to a data structure for a short period of time (one RCU critical section), as long as you release it quickly. Outside the RCU critical section, the data structure can be destroyed, and you will not be able to claim it again.

So the advantage over krefs is simply that it's clear with a revocable reference that you have to check that the referent still exists every time you enter a critical section that needs access; you can, of course, implement this in an ad-hoc way for every piece of hardware that benefits from this, but it's clearer for reviewers if you implement it once and have a common pattern to reuse.

Revocable references vs. krefs

Alan.Stern — Thu, 25 Sep 2025 18:18:30 +0000

In what way are revocable references better than the existing practice of reference-counting using krefs?

Cancellations in debugfs

benzea — Tue, 23 Sep 2025 07:23:37 +0000

That reminds me of the debugfs file removal race conditions we had in cfg80211. To solve those, we added the debugfs_enter_cancellation()/debugfs_leave_cancellation() API. The idea there is to have a callback that permits notifying the user asynchronously that the resource (the debugfs file in this case) is being removed and any outstanding file operation need to be cancelled ASAP.

In the cfg80211 case, the user file operations are handled by queuing a work item that will then hold the wiphy mutex. However, if the debugfs file is removed before it runs, then the work item is simply cancelled so that the file removal can go ahead immediately.

It does not look to me like this API can easily be used for this debugfs use in cfg80211. That is probably fine, but it could still be an interesting usage scenario to look at.

I thought that had a familiar ring to it

fman — Mon, 22 Sep 2025 20:57:25 +0000

Reminds me of the Macintosh toolbox Handle's..
HLock(h) & HUnlock(h) anyone ..