Re: [PATCH 0/3] Revert "revocable: Revocable resource management"

[Johan Hovold <johan@kernel.org>]

On Tue, Jan 27, 2026 at 10:18:27PM +0100, Bartosz Golaszewski wrote:
> On Mon, Jan 26, 2026 at 2:50 PM Johan Hovold <johan@kernel.org> wrote:

> > It's certainly possible to handle the chardev unplug issue without
> > revocable as several subsystems already do. All you need is a refcount,
> > a lock and a flag.
> >
> > It may be possible to provide a generic solutions at the chardev level
> > or some kind of helper implementation (similar to revocable) for
> > subsystems to use directly.
>
> This echoes the heated exchange I recently had with Johan elsewhere so
> I would like to chime in and use the wider forum of driver core
> maintainers to settle an important question. It seems there are two
> camps in this discussion: one whose perception of the problem is
> limited to character devices being referenced from user-space at the
> time of the driver unbind (favoring fixing the issues at the vfs
> level) and another extending the problem to any driver unbinding where
> we cannot ensure a proper ordering of the teardown (for whatever
> reason: fw_devlink=off, helper auxiliary devices acting as
> intermediates, or even user-space unbinding a driver manually with
> bus-level sysfs attributes) leaving consumers of resources exposed by
> providers that are gone with dangling references (focusing the
> solutions on the subsystem level).

What I've been trying to get across is that the chardev hot-unplug issue
is real and needs to be fixed where it still exists, while the manual
unbinding of drivers by root is a corner case which does not need to be
addressed at *any* cost.

If addressing the latter by wrapping every resource access in code that
adds enough runtime overhead and makes drivers harder to write and
maintain it *may* not be worth it and we should instead explore
alternatives.

This may involve tracking consumers like fw_devlink already does today
so that they are unbound before their dependencies are.

Because in the end, how sound is a model where we allow critical
resources to silently go away while a device is still in use (e.g. you
won't discover that your emergency shutdown gpio is gone until you
actually need it)?

Johan