Re: [PATCH v3 0/5] platform/chrome: Fix a possible UAF via revocable

["Danilo Krummrich" <dakr@kernel.org>]

On Mon Sep 22, 2025 at 5:10 PM CEST, Jason Gunthorpe wrote:
> As was said later in this thread, it would be a real shame to see
> people implement revocable in drivers instead of rely on subsystems to
> have sane unregistration semantics where the subsystem guarentees that
> no driver callbacks are running after unregister. You never need
> driver revocable in a world like that.

I fully agree with that, in C there is indeed no value of a revocable type when
subsystems can guarantee "sane unregistration semantics".

I say "in C" because in C there is no way to get a proof by the compiler that
we're in a scope (e.g. through the subsystem guarentee) where the device is
guaranteed to be bound (which we can in Rust).

So, effectively, we're not getting any value out of the revocable in C in such a
case: In the best case, we're just bypassing the revocable by accessing the
pointer unchecked (regardless whether that's valid or not); in the worst case
we're introducing a useless SRCU read side critical section.

(In Rust the compiler will stop us from accessing the pointer unchecked if we're
not in a scope where unchecked access is valid.)

So, I think in C revocable should be restricted to use-cases where scopes are
unbound by design. DRM device callbacks are an example for that and it's the
reason why things like drm_dev_{enter,exit}() and drm_dev_unplug() exist. In the
end, those are exactly the same as revocable implemented in a slightly different
way.

- Danilo