linux-kernel - Re: [PATCH 1/3] lib: Add ref

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: <DC22V4IMAJ1Q.3HJUK21LRN5D5@kernel.org>
Date: Thu, 14 Aug 2025 12:27:32 +0200
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Greg KH" <gregkh@...uxfoundation.org>
Cc: "Tzung-Bi Shih" <tzungbi@...nel.org>, <bleung@...omium.org>,
 <dawidn@...gle.com>, <chrome-platform@...ts.linux.dev>,
 <akpm@...ux-foundation.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/3] lib: Add ref_proxy module

On Thu Aug 14, 2025 at 12:05 PM CEST, Greg KH wrote:
> I've added Danilo here, as hopefully this is doing much the same thing
> that his rust code does, but I think it's using different names?

It does exactly the same thing as we do in Rust with Devres [1] and
Revocable [2].

The only difference is that this uses SRCU whereas the Rust stuff uses RCU.

One reason Rust is using RCU rather than SRCU is that in almost all cases
we can avoid the need for synchronization at all, by having a proof through the
type system that we're accessing the resource from a context where we can
guarantee that the device is bound, i.e. we have the guarantee that it can't be
unbound concurrently.

While for the few cases we hit where we can't proove that the device is bound
anyways, we don't need a sleepable context and rather keep the critical section
short in order to not delay device unbind too much.

> Danilo, any ideas if this matches up with what we have in the driver
> core rust code now, and would it help out with the drm drivers as well?

As mentioned it matches almost exactly. However, I don't think it'd be worth
building abstractions for it in Rust and use those instead, we can do it with
less code and in a more ideomatic way in Rust right away.

However, *both* this and the Rust Revocable suffer from the same problem, which
I have on my list to solve. That is, we have a synchronize_{srcu,rcu}() call for
every devres node being dropped on driver unbind. Where, instead, we want devres
to provide two callbacks; the first one where we revoke the resource (in C this
would be the call to rcu_assign_pointer(rpp->ref, NULL)), subsequently call
synchronize_{srcu,rcu}() exactly *once* and then have the second callback to
free / drop all the resources.

I'll also reply to the patch itself.

[1] https://rust.docs.kernel.org/kernel/devres/struct.Devres.html
[2] https://rust.docs.kernel.org/kernel/revocable/struct.Revocable.html