On Mon, Sep 28, 2026 at 12:32:34PM +0100, Gary Guo wrote: [...] > >> For some context, the current Rust revocable implementation uses RCU, but > >> this > >> is limiting the case where it can be used. The current C revocable series > >> in > >> https://lore.kernel.org/all/[email protected]/ uses > >> SRCU. > >> > >> I think this use case is a good one for hazptr, in fact, I have encouraged > >> Alvin > >> Sun to try it out and you can see an implementation (Rust) in here: > >> https://lore.kernel.org/rust-for-linux/[email protected]/ > >> Although, over the course of the year, we have been reducing the amount of > >> revocable usage and shifting to represent things with lifetime.. > >> > > > > Paul asked me for the Rust usage a few days ago, and since we moved to > > a lifetime based approach [1], which is better IMO, I don't think > > switching to hazptr will should observable difference here, especially > > for a real workload improvement. It's still worth trying to see how > > hazptr in Rust would work for this, but it's less a sufficient condition > > to merge hazptr from my understanding. Of course I could be wrong. > > > > [1]: > > https://lore.kernel.org/rust-for-linux/[email protected]/ > > What we get rid of is to use `Revocable` (or `DevRes`) to protect resources > where we _know_ that the resource is alive (for example, in device private > data, > because it's teared down by driver-core on unbind). > > However, there are cases where we can still have the `Revocable` pattern, for > example when a class device is exposed to userspace and the bus device is > unbinding. This is a pretty recurring pattern too, and cannot be handled via > lifetime alone. This is what motivates the C revocable series. >
Not trying to discourage switching to hazptr in `Revocable`, but I think the only shortcoming of RCU there is "unable to sleep while referencing a `Revocable`", right? Certainly hazptr can help on that but so does SRCU. I'm unsure hazptr can show observable advantages against SRCU here. But I could be wrong. Regards, Boqun > Best, > Gary
