linux-kernel - Re: [PATCH v7 0/3] drivers/base: Introduce revocable

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: <20260116165242.GO961588@nvidia.com>
Date: Fri, 16 Jan 2026 12:52:42 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Danilo Krummrich <dakr@...nel.org>
Cc: Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Tzung-Bi Shih <tzungbi@...nel.org>,
	Benson Leung <bleung@...omium.org>,
	"Rafael J . Wysocki" <rafael@...nel.org>,
	Bartosz Golaszewski <brgl@...ev.pl>,
	Linus Walleij <linusw@...nel.org>, Jonathan Corbet <corbet@....net>,
	Shuah Khan <shuah@...nel.org>, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, chrome-platform@...ts.linux.dev,
	linux-kselftest@...r.kernel.org,
	Wolfram Sang <wsa+renesas@...g-engineering.com>,
	Simona Vetter <simona.vetter@...ll.ch>,
	Dan Williams <dan.j.williams@...el.com>, linux-gpio@...r.kernel.org
Subject: Re: [PATCH v7 0/3] drivers/base: Introduce revocable

On Fri, Jan 16, 2026 at 05:16:58PM +0100, Danilo Krummrich wrote:
> On Fri Jan 16, 2026 at 5:04 PM CET, Laurent Pinchart wrote:
> > The revocable mechanism isn't the right solution for races between device
> > removal and userspace access.
> 
> I think you have to differenciate, as it depends on the resource:
> 
> If the resource is a device resource (e.g. MMIO resource regions) that must not
> be held by the driver after its bound device has been unbound, you have to
> revoke the resource from the driver, i.e. you can't just fix it with a reference
> count.

The C code doesn't really work like that, it works on sync teardown
flows. If you want to write correct C code you need to think about all
the concurrency the driver has and ensure that removal undoes it

I think Laurent is referring to the lack of a sync unregister for
fops.

In this series patches 13-16 are all fops related callbacks.

#17 kind of looks like a cancel_work_sync() is missing (ie what is
preventing this work func from running after the module unloads?)

#19 is all sysfs stuff, and sysfs already has a sync unregister, so
maybe these SRCU's can never fail?

Jason