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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aXovtrAM1r1UyWxA@hovoldconsulting.com>
Date: Wed, 28 Jan 2026 16:48:06 +0100
From: Johan Hovold <johan@...nel.org>
To: Bartosz Golaszewski <bartosz.golaszewski@....qualcomm.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Danilo Krummrich <dakr@...nel.org>,
	"Rafael J . Wysocki" <rafael@...nel.org>,
	Tzung-Bi Shih <tzungbi@...nel.org>,
	Linus Walleij <linusw@...nel.org>, Jonathan Corbet <corbet@....net>,
	Shuah Khan <shuah@...nel.org>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Wolfram Sang <wsa+renesas@...g-engineering.com>,
	Simona Vetter <simona.vetter@...ll.ch>,
	Dan Williams <dan.j.williams@...el.com>,
	Jason Gunthorpe <jgg@...dia.com>, linux-doc@...r.kernel.org,
	linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org,
	Bartosz Golaszewski <brgl@...nel.org>
Subject: Re: [PATCH 0/3] Revert "revocable: Revocable resource management"

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@...nel.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