linux-kernel - Re: [PATCH v7 3/6] rust: irq: add support for non-threaded IRQs and handlers

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: <CF821F27-7F78-4B3E-AF62-887341EAA7BE@collabora.com>
Date: Wed, 23 Jul 2025 13:07:32 -0300
From: Daniel Almeida <daniel.almeida@...labora.com>
To: Boqun Feng <boqun.feng@...il.com>
Cc: Miguel Ojeda <ojeda@...nel.org>,
 Alex Gaynor <alex.gaynor@...il.com>,
 Gary Guo <gary@...yguo.net>,
 Björn Roy Baron <bjorn3_gh@...tonmail.com>,
 Andreas Hindborg <a.hindborg@...nel.org>,
 Alice Ryhl <aliceryhl@...gle.com>,
 Trevor Gross <tmgross@...ch.edu>,
 Danilo Krummrich <dakr@...nel.org>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 "Rafael J. Wysocki" <rafael@...nel.org>,
 Thomas Gleixner <tglx@...utronix.de>,
 Bjorn Helgaas <bhelgaas@...gle.com>,
 Krzysztof Wilczy´nski <kwilczynski@...nel.org>,
 Benno Lossin <lossin@...nel.org>,
 linux-kernel@...r.kernel.org,
 rust-for-linux@...r.kernel.org,
 linux-pci@...r.kernel.org
Subject: Re: [PATCH v7 3/6] rust: irq: add support for non-threaded IRQs and
 handlers

[…]

>> 
>> 
>> Because it is not as explicit. The main thing we should be conveying to users
>> here is how to get a &mut or otherwise mutate the data when running the
>> handler. When people see AtomicU32, it's a quick jump to "I can make this work
>> by using other locks, like SpinLockIrq". Completions hide this, IMHO.
>> 
> 
> I understand your argument. However, I'm not sure the example of
> `irq::Registration` is the right place to do this. On one hand, it's one
> of the usage of interior mutability as you said, but on the other hand,
> for people who are familiar with interior mutability, the difference
> between `AtomicU32` and `Completion` is not that much. That's kinda my
> argument why using `Completion` in the example here is fine.
> 
> Sounds reasonable?
> 
>> It's totally possible for someone to see this and say "ok, I can call
>> complete() on this, but how can I mutate the data in some random T struct?",
>> even though these are essentially the same thing from an interior mutability
>> point of view.
>> 
> 
> We probably better assume that interior mutability is commmon knowledge
> or we could make an link to some documentation of interior mutability,
> for example [1], in the documentation of `handler`. Not saying your
> effort and consideration is not valid, but at the project level,
> interior mutability should be widely acknowledged IMO.
> 
> [1]: https://doc.rust-lang.org/reference/interior-mutability.html
> 
> Regards,
> Boqun
> 
>> -- Daniel

I do expect mostly everbody (except brand-new newcomers) to be aware of
interior mutability. What I don't expect is for people _immediately_ see that
it's being used in Completion, and connect the dots from there.

Keyword here being "immediately", users will naturally realize this in a couple
of minutes at max, of course.

Anyways, I guess we can use Completion then. TBH I wasn't aware of the UB
thing, so I can see how you also have a point. On top of that, we can use the
words "interior mutability" somewhere in the example as well to make it even
clearer.

I'll change it for v8.

-- Daniel