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: <DFXQ915MAG5K.2KYVQOTF056N5@kernel.org>
Date: Sun, 25 Jan 2026 15:07:41 +0100
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Laurent Pinchart" <laurent.pinchart@...asonboard.com>
Cc: "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>, "Johan Hovold"
 <johan@...nel.org>, "Rafael J . Wysocki" <rafael@...nel.org>, "Tzung-Bi
 Shih" <tzungbi@...nel.org>, "Bartosz Golaszewski"
 <bartosz.golaszewski@....qualcomm.com>, "Linus Walleij"
 <linusw@...nel.org>, "Jonathan Corbet" <corbet@....net>, "Shuah Khan"
 <shuah@...nel.org>, "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>
Subject: Re: [PATCH 0/3] Revert "revocable: Revocable resource management"

On Sun Jan 25, 2026 at 2:22 PM CET, Laurent Pinchart wrote:
> It's the wrong solution for most cases, if not all. It will spread in drivers
> and then become another big piece of technical debt we'll wish we had never
> merged.

It is a matter of how the revocable pattern is adopted. I.e. I don't think
drivers should create instances of revocable (device) resources by themselves.
Instead, I think it should be up to the corresponding subsystems to adopt the
pattern in the way necessary and make it accessible to drivers instead.

> We know what the right solution to the cdev race is

So, what is it? Assuming that this is what you are referring to, how do you
prevent accesses to (potentially freed) device resources after the bus device
has been unbound from the driver for subsystems that may still call back into
the driver after device unbind?