On Fri, Jan 16, 2026 at 7:24 PM Jason Gunthorpe [off-list ref] wrote:

On Fri, Jan 16, 2026 at 07:19:50PM +0100, Bartosz Golaszewski wrote:

quoted

On Fri, Jan 16, 2026 at 5:41 PM Danilo Krummrich [off-list ref] wrote:

quoted

On Fri Jan 16, 2026 at 5:04 PM CET, Laurent Pinchart wrote:

quoted

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/DFQ5D44A0348.PZJIGPL972N@kernel.org/ (local)

quoted

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