linux-kernel - Re: [PATCH v5 6/9] rust: bitfield: Add KUNIT tests for bitfield

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] [day] [month] [year] [list]

Message-ID: <a7acc840-8d95-451a-b431-f3755ad6f37c@weathered-steel.dev>
Date: Thu, 2 Oct 2025 03:35:03 +0000
From: Elle Rhumsaa <elle@...thered-steel.dev>
To: Alexandre Courbot <acourbot@...dia.com>,
 Joel Fernandes <joelagnelf@...dia.com>, linux-kernel@...r.kernel.org,
 rust-for-linux@...r.kernel.org, dri-devel@...ts.freedesktop.org,
 dakr@...nel.org
Cc: Alistair Popple <apopple@...dia.com>, Miguel Ojeda <ojeda@...nel.org>,
 Alex Gaynor <alex.gaynor@...il.com>, Boqun Feng <boqun.feng@...il.com>,
 Gary Guo <gary@...yguo.net>, bjorn3_gh@...tonmail.com,
 Benno Lossin <lossin@...nel.org>, Andreas Hindborg <a.hindborg@...nel.org>,
 Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>,
 David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
 John Hubbard <jhubbard@...dia.com>, Timur Tabi <ttabi@...dia.com>,
 joel@...lfernandes.org, Yury Norov <yury.norov@...il.com>,
 Daniel Almeida <daniel.almeida@...labora.com>,
 Andrea Righi <arighi@...dia.com>, nouveau@...ts.freedesktop.org
Subject: Re: [PATCH v5 6/9] rust: bitfield: Add KUNIT tests for bitfield


On 10/2/25 2:51 AM, Alexandre Courbot wrote:
> On Thu Oct 2, 2025 at 11:16 AM JST, Elle Rhumsaa wrote:
>> On 10/2/25 1:41 AM, Alexandre Courbot wrote:
>>
>>> On Tue Sep 30, 2025 at 11:45 PM JST, Joel Fernandes wrote:
>>>> Add KUNIT tests to make sure the macro is working correctly.
>>>>
>>>> Signed-off-by: Joel Fernandes <joelagnelf@...dia.com>
>>>> ---
>>>>    rust/kernel/bitfield.rs | 321 ++++++++++++++++++++++++++++++++++++++++
>>>>    1 file changed, 321 insertions(+)
>>>>
>>>> diff --git a/rust/kernel/bitfield.rs b/rust/kernel/bitfield.rs
>>>> index fed19918c3b9..9a20bcd2eb60 100644
>>>> --- a/rust/kernel/bitfield.rs
>>>> +++ b/rust/kernel/bitfield.rs
>>>> @@ -402,3 +402,324 @@ fn default() -> Self {
>>>>            }
>>>>        };
>>>>    }
>>>> +
>>>> +#[::kernel::macros::kunit_tests(kernel_bitfield)]
>>>> +mod tests {
>>>> +    use core::convert::TryFrom;
>>>> +
>>>> +    // Enum types for testing => and ?=> conversions
>>>> +    #[derive(Debug, Clone, Copy, PartialEq)]
>>>> +    enum MemoryType {
>>>> +        Unmapped = 0,
>>>> +        Normal = 1,
>>>> +        Device = 2,
>>>> +        Reserved = 3,
>>>> +    }
>>>> +
>>>> +    impl Default for MemoryType {
>>>> +        fn default() -> Self {
>>>> +            MemoryType::Unmapped
>>>> +        }
>>>> +    }
>>> Tip: you can add `Default` to the `#[derive]` marker of `MemoryType` and
>>> mark the variant you want as default with `#[default]` instead of
>>> providing a full impl block:
>>>
>>>       #[derive(Debug, Default, Clone, Copy, PartialEq)]
>>>       enum MemoryType {
>>>           #[default]
>>>           Unmapped = 0,
>>>           Normal = 1,
>>>           Device = 2,
>>>           Reserved = 3,
>>>       }
>> I would alternatively recommend to provide a `MemoryType::new` impl with
>> a `const` definition:
>>
>> ```rust
>> impl MemoryType {
>>       pub const fn new() -> Self {
>>
>>           Self::Unmapped
>>
>>       }
>> }
>>
>> impl Default for MemoryType {
>>       fn default() -> Self {
>>           Self::new()
>>       }
>> }
>> ```
>>
>> This pattern allows using `MemoryType::new()` in `const` contexts, while
>> also providing the `Default` impl using the same default. It's somewhat
>> of a workaround until we get `const` traits.
> That's an elegant pattern generally speaking, but I don't think we would
> benefit from using it in these unit tests.

*facepalm* right, I lost the context that these data structures were 
KUNIT-specific. Please disregard.