linux-kernel - Re: [PATCH v6 2/6] rust: irq: add flags module

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: <82EFFBBD-C6BF-444C-9209-70805E31EE9E@collabora.com>
Date: Sat, 12 Jul 2025 17:48:30 -0300
From: Daniel Almeida <daniel.almeida@...labora.com>
To: Alice Ryhl <aliceryhl@...gle.com>
Cc: Daniel Sedlak <daniel@...lak.dev>,
 Miguel Ojeda <ojeda@...nel.org>,
 Alex Gaynor <alex.gaynor@...il.com>,
 Boqun Feng <boqun.feng@...il.com>,
 Gary Guo <gary@...yguo.net>,
 Björn Roy Baron <bjorn3_gh@...tonmail.com>,
 Andreas Hindborg <a.hindborg@...nel.org>,
 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>,
 Benno Lossin <lossin@...nel.org>,
 Bjorn Helgaas <bhelgaas@...gle.com>,
 Krzysztof Wilczyński <kwilczynski@...nel.org>,
 linux-kernel@...r.kernel.org,
 rust-for-linux@...r.kernel.org,
 linux-pci@...r.kernel.org
Subject: Re: [PATCH v6 2/6] rust: irq: add flags module

> On 12 Jul 2025, at 17:03, Alice Ryhl <aliceryhl@...gle.com> wrote:
> 
> On Sat, Jul 12, 2025 at 6:27 PM Daniel Almeida
> <daniel.almeida@...labora.com> wrote:
>> 
>> Hi Alice,
>> 
>>> On 4 Jul 2025, at 04:42, Alice Ryhl <aliceryhl@...gle.com> wrote:
>>> 
>>> On Fri, Jul 04, 2025 at 08:14:11AM +0200, Daniel Sedlak wrote:
>>>> Hi Daniel,
>>>> 
>>>> On 7/3/25 9:30 PM, Daniel Almeida wrote:
>>>>> +/// Flags to be used when registering IRQ handlers.
>>>>> +///
>>>>> +/// They can be combined with the operators `|`, `&`, and `!`.
>>>>> +#[derive(Clone, Copy, PartialEq, Eq)]
>>>>> +pub struct Flags(u64);
>>>> 
>>>> Why not Flags(u32)? You may get rid of all unnecessary casts later, plus
>>>> save some extra bytes.
>>> 
>>> It looks like the C methods take an `unsigned long`. In that case, I'd
>>> probably write the code to match that.
>>> 
>>> pub struct Flags(c_ulong);
>>> 
>>> and git rid of the cast when calling bindings::request_irq.
>>> 
>>> As for all the constants in this file, maybe it would be nice with a
>>> private constructor that uses the same type as bindings to avoid the
>>> casts?
>>> 
>>> impl Flags {
>>>   const fn new(value: u32) -> Flags {
>>>    ...
>>>   }
>>> }
>> 
>> 
>> Sure, but what goes here? This has to be "value as c_ulong” anyways so it
>> doesn’t really reduce the number of casts.
>> 
>> We should probably switch to Flags(u32) as Daniel Sedlak suggested. Then
>> it’s a matter of casting once for bindings::request_irq().
> 
> IMO the advantage of doing it here is that we can fail compilation if
> the cast is out of bounds, whereas the other cast is at runtime so we
> can't do that.
> 
> Alice

I’m not sure I am following. How is this compile-time checked?

>>> impl Flags {
>>>   const fn new(value: u32) -> Flags {
>>>    Self(value as c_ulong)
>>>   }

Or perhaps I misunderstood you?

— Daniel