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: <DDPU75QB8MQ6.3HZ5N0GYKQ9QU@kernel.org>
Date: Thu, 23 Oct 2025 18:20:02 +0200
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Jason Gunthorpe" <jgg@...dia.com>
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 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.

The idea is to utilize this pattern for every applicable scope, e.g. workqueues /
work items, timers, IRQs, substems callbacks, IOCTLs, etc.

Only for scopes where no such guarantee can be given upheld, the caller actually
has to go through the Revocable. And this is good, because it means the caller
is indeed in a scope where there is no guarantee that the device is not unbound
concurrently.

So, what the Rust code aims at, is to guarantee correctness in either case. But
in order to achieve that without unnecessary overhead, all the other APIs (e.g.
IRQ, workqueue, etc.) have to provide specific "sync" APIs playing along the
driver model.

The difference between C and Rust here is mostly that the "safely bypass
Revocable" trick is only possible due to Rust's type system (and hence the
compiler) stopping people from doing it in an unsafe way. In C that's not
possible unfortunately.