On Fri, Jan 16, 2026 at 7:24 PM Jason Gunthorpe <[email protected]> wrote: > > On Fri, Jan 16, 2026 at 07:19:50PM +0100, Bartosz Golaszewski wrote: > > On Fri, Jan 16, 2026 at 5:41 PM Danilo Krummrich <[email protected]> wrote: > > > > > > On Fri Jan 16, 2026 at 5:04 PM CET, Laurent Pinchart wrote: > > > > Based on the discussions we had at LPC, the revocable resource > > > > management API > > > > is not the right solution to handle races between device removal and > > > > userspace > > > > access. > > > > > > Please see: > > > https://lore.kernel.org/all/[email protected]/ > > > > > > > It is however a possibly useful tool for races between producers and > > > > consumers > > > > *inside the kernel*. > > > > > > Do you have an example for such a case? > > > > Isn't the GPIO use-case - which the series on top of it addresses - one? > > > > With fw_devlink=off it's quite easy to trigger all kinds of crashes > > with in-kernel users. > > Does this series solve that? It looked to me like it just replaces the > existing SRCU with a wrapper? >
SRCU already *did* solve it. Revocable *is* a wrapper around SRCU that generalizes the initial solution. Replacing SRCU with a generalized wrapper is fine but there are subsystems out there, where the problem is much less trivial. Take I2C for example: the struct device management is so broken that there isn't even anything *to revoke* yet. It'll take years of little reworks before we can even use revocable at all. I'm not against it as a library of functions. But TBH I looked at the series and - besides making the code run slower - it also kind of makes it harder to read. With *naked* SRCU it's very clear what's going on, when you start hiding the logic, it becomes needlessly obfuscated. I want to first see revocable match current GPIO performance and then we can talk about accepting it. Bartosz
