linux-kernel - Re: [PATCH v3 4/5] rust: id_pool: do not immediately acquire new ids

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: <DDU7649EY2RW.NX9QCDBO09BE@kernel.org>
Date: Tue, 28 Oct 2025 20:20:35 +0100
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Yury Norov" <yury.norov@...il.com>
Cc: "Alice Ryhl" <aliceryhl@...gle.com>, "Greg Kroah-Hartman"
 <gregkh@...uxfoundation.org>, Arve Hjønnevåg
 <arve@...roid.com>, "Todd Kjos" <tkjos@...roid.com>, "Martijn Coenen"
 <maco@...roid.com>, "Joel Fernandes" <joelagnelf@...dia.com>, "Christian
 Brauner" <brauner@...nel.org>, "Carlos Llamas" <cmllamas@...gle.com>,
 "Suren Baghdasaryan" <surenb@...gle.com>, "Burak Emir" <bqe@...gle.com>,
 "Miguel Ojeda" <ojeda@...nel.org>, "Boqun Feng" <boqun.feng@...il.com>,
 "Gary Guo" <gary@...yguo.net>, Björn Roy Baron
 <bjorn3_gh@...tonmail.com>, "Benno Lossin" <lossin@...nel.org>, "Andreas
 Hindborg" <a.hindborg@...nel.org>, "Trevor Gross" <tmgross@...ch.edu>,
 <rust-for-linux@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 4/5] rust: id_pool: do not immediately acquire new
 ids

On Tue Oct 28, 2025 at 7:42 PM CET, Yury Norov wrote:
> I'm not sure about this change, but it looks like a lock wrapping
> acquire_next_id().

It leverages the borrow concept of Rust [1].

The Rust compiler ensures that a mutable reference is exclusive, so there can't
be two independent mutable borrows at a time.

This means that if an object A has a mutable reference of another object B, the
compiler prevents a third object C to have a (mutable) reference of B as well.

So what this ensures is that object A has exclusive access to object B within
the same task -- no concurrency involved.

The way this is connected with concurrency and locks is that if an object is
shared between tasks, you would need a lock to obtain a mutable reference, i.e.
the lock provides the precondition for exclusive access.

So, (mutable) references are about ownership, not synchronization.

I sketched up a simplified and runnable example of the idea behind Alice' code
in [2] to play with, in case you are interested -- I think that clarifies it
best. :)

[1] https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=5e67f1ea36b7e4561bcf5b41137284ec
[2] https://doc.rust-lang.org/book/ch04-02-references-and-borrowing.html