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: <20260129010948.GD3275574@killaraus>
Date: Thu, 29 Jan 2026 03:09:48 +0200
From: Laurent Pinchart <laurent.pinchart@...asonboard.com>
To: Danilo Krummrich <dakr@...nel.org>
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 03:07:41PM +0100, Danilo Krummrich wrote:
> 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?

I've answered this question in another e-mail in this thread, see
https://lore.kernel.org/all/20260129010822.GA3310904@killaraus/

-- 
Regards,

Laurent Pinchart