| 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
| ||
|
Message-ID: <5642a7f2-c18f-46cf-8136-9fccd1c121ae@nvidia.com>
Date: Wed, 10 Sep 2025 19:22:03 -0400
From: Joel Fernandes <joelagnelf@...dia.com>
To: Yury Norov <yury.norov@...il.com>
Cc: linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
dakr@...nel.org, acourbot@...dia.com, 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, Elle Rhumsaa <elle@...thered-steel.dev>,
Daniel Almeida <daniel.almeida@...labora.com>, nouveau@...ts.freedesktop.org
Subject: Re: [PATCH v3 5/5] rust: Add KUNIT tests for bitfield
Hi Jury,
Some reason I messed up with my email client while trimming, so I am re-sending.
Sorry :)
On 9/9/2025 11:04 PM, Yury Norov wrote:
[...]
>> + #[test]
>> + fn test_range_fields() {
>> + let mut pte = TestPageTableEntry::default();
>> +
>> + pte = pte.set_pfn(0x123456);
>> + assert_eq!(pte.pfn(), 0x123456);
>> + // Test overlapping field reads same value
>> + assert_eq!(pte.pfn_overlap(), 0x123456);
>> +
>> + pte = pte.set_available(0x7);
>> + assert_eq!(pte.available(), 0x7);
>> +
>> + pte = pte.set_available2(0x3FF);
>> + assert_eq!(pte.available2(), 0x3FF);
>> +
>> + // Test TryFrom with ?=> for MemoryType
>> + pte = pte.set_mem_type(MemoryType::Device);
>> + assert_eq!(pte.mem_type(), Ok(MemoryType::Device));
>> +
>> + pte = pte.set_mem_type(MemoryType::Normal);
>> + assert_eq!(pte.mem_type(), Ok(MemoryType::Normal));
>> +
>> + // Test all valid values for mem_type
>> + pte = pte.set_mem_type(MemoryType::Reserved); // Valid value: 3
>> + assert_eq!(pte.mem_type(), Ok(MemoryType::Reserved));
>> +
>> + // Test failure case using extended_type field which has 4 bits (0-15)
>> + // MemoryType only handles 0-3, so values 4-15 should return Err
>> + let mut raw = pte.raw();
>> + raw = (raw & !(0xF << 14)) | (0x7 << 14); // Set bits 17:14 to 7 (invalid for MemoryType)
>> + let invalid_pte = TestPageTableEntry::from(raw);
>> + assert_eq!(invalid_pte.extended_type(), Err(0x7)); // Should return Err with the invalid value
>
> Please make sure your lines don't exceed 100 chars, preferably less
> than 80.
Ok.
>> +
>> + // Test a valid value after testing invalid to ensure both cases work
>> + raw = (raw & !(0xF << 14)) | (0x2 << 14); // Set bits 17:14 to 2 (valid: Device)
>
> Can you use genmask!() here and everywhere else?
Ok.
>> + #[test]
>> + fn test_u8_bitfield() {
>> + let mut status = TestStatusRegister::default();
>> +
>> + assert!(!status.ready());
>> + assert!(!status.error());
>> + assert_eq!(status.state(), 0);
>> + assert_eq!(status.reserved(), 0);
>> + assert_eq!(status.full_byte(), 0);
>> +
>> + status = status.set_ready(true);
>> + assert!(status.ready());
>> + assert_eq!(status.full_byte(), 0x01);
>> +
>> + status = status.set_error(true);
>> + assert!(status.error());
>> + assert_eq!(status.full_byte(), 0x03);
>> +
>> + status = status.set_state(0x3);
>> + assert_eq!(status.state(), 0x3);
>> + assert_eq!(status.full_byte(), 0x0F);
>> +
>> + status = status.set_reserved(0xA);
>> + assert_eq!(status.reserved(), 0xA);
>> + assert_eq!(status.full_byte(), 0xAF);
>> +
>> + // Test overlapping field
>> + status = status.set_full_byte(0x55);
>> + assert_eq!(status.full_byte(), 0x55);
>> + assert!(status.ready());
>> + assert!(!status.error());
>> + assert_eq!(status.state(), 0x1);
>> + assert_eq!(status.reserved(), 0x5);
>> +
>> + let status2 = TestStatusRegister::default()
>> + .set_ready(true)
>> + .set_state(0x2)
>> + .set_reserved(0x5);
>> +
>> + assert!(status2.ready());
>> + assert!(!status2.error());
>> + assert_eq!(status2.state(), 0x2);
>> + assert_eq!(status2.reserved(), 0x5);
>> + assert_eq!(status2.full_byte(), 0x59);
>> +
>> + let raw_value: u8 = 0x59;
>> + let status3 = TestStatusRegister::from(raw_value);
>> + assert_eq!(status3.raw(), raw_value);
>> + assert!(status3.ready());
>> + assert!(!status3.error());
>> + assert_eq!(status3.state(), 0x2);
>> + assert_eq!(status3.reserved(), 0x5);
>> + assert_eq!(status3.full_byte(), 0x59);
>
> You've got only one negative test that covers the .from() method.
> Can you add more?
>
Sure, by negative you mean the test that returned an error code? If so, just to
note, we can only add negative tests if there is a chance of
runtime failure, which at runtime can mainly happen with the fallible usage (?=>
pattern). Also just to note, we already at ~300 lines of test code now :)
> What if I create a bitfield from a runtime value that exceeds
> the capacity?
>
> bitfield! {
> struct bf: u8 {
> 0:0 ready as bool;
> 1:1 error as bool;
> 3:2 state as u32;
Here you mean 'as u8', otherwise it wont compile.
> }
> }
>
> let raw_value: u8 = 0xff;
> let bf = bf::from(raw_value);
>
> I guess you'd return None or similar.
No, we would ignore the extra bits sent. There is a .raw() method and 'bf' is
8-bits, bf.raw() will return 0xff. So it is perfectly valid to do so. I don't
think we should return None here, this is also valid in C.
> Can you add such a test?
Sure, I added such a test.
> The same question for the setters. What would happen for this:
>
> let bf = bf::default()
> .set_state(0xf)
> .set_ready(true);
>
> I think that after the first out-of-boundary in set_state(), you
> should abort the call chain, make sure you're not touching memory
> in set_ready() and returning some type of error.
Here, on out of boundary, we just ignore the extra bits passed to set_state. I
think it would be odd if we errored out honestly. We are using 'as u8' in the
struct so we would accept any u8 as input, but then if we complained that extra
bits were sent, that would be odd. In C also this is valid. If you passed a
higher value than what the bitfield can hold, the compiler will still just use
the bits that it needs and ignore the rest.
Now, I am not opposed to error'ing out on that, but that's not what we currently
do and it is also not easy to do. The setters in the patch return Self, not
Result<Self>, so they are infallible, which is what allows them to be chained as
well (builder pattern).
I added another test here as well, to ensure the behavior is as I describe.
>
> And for this:
>
> let ret: u32 = -EINVAL;
> bf = bf::default();
> bf = bf.set_state(ret);
>
> For compile-time initializes, it should be a compile-time error, right?
Yes, since the struct in this example is u8, this wont compile. Yes, I will add
a comment.
> Can you drop a comment on that?
Yes, I will do so.
> (In C we've got FIELD_{GET,MODIFY,PREP}. They cover all the static
> cases.)
>
>> + let status4 = TestStatusRegister::from(0xFF);
>> + assert!(status4.ready());
>> + assert!(status4.error());
>> + assert_eq!(status4.state(), 0x3);
>> + assert_eq!(status4.reserved(), 0xF);
>> + assert_eq!(status4.full_byte(), 0xFF);
>> + }
>> +}
>> --
>> 2.34.1
>
> I tried to apply your series on top of master, but it failed. So
> my apologies for not finding the answers to some questions above
> by myself.
Oh ok, I applied it on top of drm-rust-next. I will rebase on -next for the next
revision, thanks.
> For the next version, can you make sure your series is applicable
> on top of master or -next?
Sure, thanks,
- Joel
Powered by blists - more mailing lists