linux-kernel - Re: [PATCH v5 5/7] revocable: Add fops replacement

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: <20251023164809.GN262900@nvidia.com>
Date: Thu, 23 Oct 2025 13:48:09 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Danilo Krummrich <dakr@...nel.org>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Tzung-Bi Shih <tzungbi@...nel.org>,
	Benson Leung <bleung@...omium.org>,
	"Rafael J . Wysocki" <rafael@...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,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Bartosz Golaszewski <brgl@...ev.pl>,
	Wolfram Sang <wsa+renesas@...g-engineering.com>,
	Simona Vetter <simona.vetter@...ll.ch>,
	Dan Williams <dan.j.williams@...el.com>
Subject: Re: [PATCH v5 5/7] revocable: Add fops replacement

On Thu, Oct 23, 2025 at 06:20:02PM +0200, Danilo Krummrich wrote:
> On Thu Oct 23, 2025 at 5:57 PM CEST, Jason Gunthorpe wrote:
> > IMHO the rust code does it principally because the sync unregister
> > life cycle model does not fit naturally into rust.
> 
> That's not the case.
> 
> In fact, we try to give as much "sync" guarantees as possible. For instance,
> when a driver registers an IRQ the irq::Registration API enforces that the IRQ
> is unregistered before the registering device is unbound.
> 
> As a consequence, the IRQ callback can provide a &Device<Bound>, which acts as a
> "cookie" that proves that for this scope (IRQ callback) the device is guaranteed
> to be bound.
> 
> With this "cookie" we can then directly access device resources (such as I/O
> memory) that is within a Devres (and hence a Revocable) container directly,
> *without* any locking. I.e. we can safely bypass the Revocable and hence its
> overhead.

It is good news to hear it, but I think you are making the point I was
trying to make.

In rust if you have a Device<bound> and you skip the revocable
locking, I'd argue that you don't need "revocable" at all, just
enforcement of a Device<bound>.

IOW the presence of revocable in rust, with all the locking, is
because the sync life cycle model is not available.

Sounds like the idea is that the sync model will be widely available
and the revocable lock will rarely be used?

Jason