Message-ID: <7a88da9f-c67b-4a68-b8d6-a66f9096bab4@nvidia.com>
Date: Mon, 1 Dec 2025 15:32:02 -0500
From: Joel Fernandes <joelagnelf@...dia.com>
To: John Hubbard <jhubbard@...dia.com>, linux-kernel@...r.kernel.org,
 rust-for-linux@...r.kernel.org, dri-devel@...ts.freedesktop.org,
 nouveau@...ts.freedesktop.org, Danilo Krummrich <dakr@...nel.org>,
 Dave Airlie <airlied@...il.com>
Cc: Alexandre Courbot <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>,
 Simona Vetter <simona@...ll.ch>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
 Timur Tabi <ttabi@...dia.com>, Joel Fernandes <joel@...lfernandes.org>,
 Lyude Paul <elle@...thered-steel.dev>,
 Daniel Almeida <daniel.almeida@...labora.com>,
 Andrea Righi <arighi@...dia.com>, Philipp Stanner <phasta@...nel.org>
Subject: Re: [PATCH v3] rust: clist: Add support to interface with C linked
 lists

Hi John,

On 11/30/2025 7:34 PM, John Hubbard wrote:
> On 11/29/25 1:30 PM, Joel Fernandes wrote:
>> Add a new module `clist` for working with C's doubly circular linked
>> lists. Provide low-level iteration over list_head nodes and high-level
>> iteration over typed list items.
> ...
>>
>>  MAINTAINERS            |   7 +
>>  rust/helpers/helpers.c |   1 +
>>  rust/helpers/list.c    |  12 ++
>>  rust/kernel/clist.rs   | 349 +++++++++++++++++++++++++++++++++++++++++
>>  rust/kernel/lib.rs     |   1 +
>>  5 files changed, 370 insertions(+)
>>  create mode 100644 rust/helpers/list.c
>>  create mode 100644 rust/kernel/clist.rs
> 
> Hi Joel,
> 
> This is sufficiently tricky that I think it needs some code to exercise it.
> 
> Lately I'm not sure what to recommend, there are several choices, each with
> trade-offs: kunit, samples/rust, or even new DRM Rust code. Maybe the last
> one is especially nice, because it doesn't really have many downsides.
> 
> Rather than wait for any of that, I wrote a quick samples/rust/rust_clist.rs
> and used it to sanity check my review findings, which are below.

In v1, I had a samples/rust/ patch, but everyone's opinion almost unanimously
was this does not belong in a sample, but rather in doctests. What in the sample
is not supported by the current doctest? If something is missing, I think I can
add it in. Plus yes, DRM_BUDDY is going to be a consumer shortly.

>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 5f7aa6a8a9a1..fb2ff877b6d1 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -22666,6 +22666,13 @@ F:	rust/kernel/init.rs
>>  F:	rust/pin-init/
>>  K:	\bpin-init\b|pin_init\b|PinInit
>>  
>> +RUST TO C LIST INTERFACES
>> +M:	Joel Fernandes <joelagnelf@...dia.com>
>> +M:	Alexandre Courbot <acourbot@...dia.com>
>> +L:	rust-for-linux@...r.kernel.org
>> +S:	Maintained
>> +F:	rust/kernel/clist.rs
>> +
>>  RXRPC SOCKETS (AF_RXRPC)
>>  M:	David Howells <dhowells@...hat.com>
>>  M:	Marc Dionne <marc.dionne@...istor.com>
>> diff --git a/rust/helpers/helpers.c b/rust/helpers/helpers.c
>> index 79c72762ad9c..634fa2386bbb 100644
>> --- a/rust/helpers/helpers.c
>> +++ b/rust/helpers/helpers.c
>> @@ -32,6 +32,7 @@
>>  #include "io.c"
>>  #include "jump_label.c"
>>  #include "kunit.c"
>> +#include "list.c"
>>  #include "maple_tree.c"
>>  #include "mm.c"
>>  #include "mutex.c"
>> diff --git a/rust/helpers/list.c b/rust/helpers/list.c
>> new file mode 100644
>> index 000000000000..6044979c7a2e
>> --- /dev/null
>> +++ b/rust/helpers/list.c
>> @@ -0,0 +1,12 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +
>> +/*
>> + * Helpers for C Circular doubly linked list implementation.
> 
> s/Circular/circular/
> 
> ...but:
> 
>> + */
>> +
>> +#include <linux/list.h>
>> +
>> +void rust_helper_list_add_tail(struct list_head *new, struct list_head *head)
>> +{
>> +	list_add_tail(new, head);
>> +}
> 
> This is, so far, not used. Let's remove it, until/unless you have some
> code in this patch(set) to use it, please.

Did you try to remove it and build the doctest? :)

  CC      rust/doctests_kernel_generated_kunit.o
error[E0425]: cannot find function `list_add_tail` in crate `bindings`
     --> rust/doctests_kernel_generated.rs:3619:19
      |
3619  |         bindings::list_add_tail(&mut (*ptr).link, head);

>> diff --git a/rust/kernel/clist.rs b/rust/kernel/clist.rs
>> new file mode 100644
>> index 000000000000..361a6132299b
>> --- /dev/null
>> +++ b/rust/kernel/clist.rs
>> @@ -0,0 +1,349 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +
>> +//! A C doubly circular intrusive linked list interface for rust code.
>> +//!
>> +//! # Examples
>> +//!
>> +//! ```
>> +//! use kernel::{
>> +//!     bindings,
>> +//!     clist::init_list_head,
>> +//!     clist_create,
>> +//!     types::Opaque, //
>> +//! };
>> +//! # // Create test list with values (0, 10, 20) - normally done by C code but it is
>> +//! # // emulated here for doctests using the C bindings.
>> +//! # use core::mem::MaybeUninit;
>> +//! #
>> +//! # /// C struct with embedded `list_head` (typically will be allocated by C code).
>> +//! # #[repr(C)]
>> +//! # pub(crate) struct SampleItemC {
>> +//! #     pub value: i32,
>> +//! #     pub link: bindings::list_head,
>> +//! # }
>> +//! #
>> +//! # let mut head = MaybeUninit::<bindings::list_head>::uninit();
>> +//! #
>> +//! # // SAFETY: head and all the items are test objects allocated in this scope.
>> +//! # unsafe { init_list_head(head.as_mut_ptr()) };
>> +//! # // SAFETY: head is a test object allocated in this scope.
>> +//! # let mut head = unsafe { head.assume_init() };
> 
> This is a bug that leads to a corrupted list. I have the test code (and
> the kernel hang/crash) to prove it.

Good find, actually it is a bug only in the example (the list construction in
your sample should be coming from C code, not rust - this code here is just for
doctest setup). That said, see below for fix.

> The problem is that any move after init_list_head() invalidates the
> list: the next/prev pointers still point to the old address.
> 
> The fix requires two-step initialization, like this, for example:

It has nothing to do with 2-step initialization. The issue is only related to
the HEAD (and not the items) right? The issue is `assume_init()` should not be
used on self-referential structures, the fix just one line:

-//! # unsafe { init_list_head(head.as_mut_ptr()) };
-//! # let mut head = unsafe { head.assume_init() };

+//! # let head = head.as_mut_ptr();
+//! # unsafe { init_list_head(head) };

Does that fix the issue in your private sample test too?

Or did I miss what you're suggesting?

> 
> //! # // Two-step init: create uninit first (can be moved), then init after.
> //! # let mut head = MaybeUninit::<bindings::list_head>::uninit();
> //! # let mut items = [
> //! #     MaybeUninit::<SampleItemC>::uninit(),
> //! #     MaybeUninit::<SampleItemC>::uninit(),
> //! #     MaybeUninit::<SampleItemC>::uninit(),
> //! # ];
> //! #
> //! # // Step 2: Now init after they're in their final location
> //! # // SAFETY: head is in its final stack location.
> //! # unsafe { init_list_head(head.as_mut_ptr()) };

Until the items are added, the items have nothing to do with the head. So I am
not sure why you have to order it this way.

> 
>> +//! # let mut items = [
>> +//! #     MaybeUninit::<SampleItemC>::uninit(),
>> +//! #     MaybeUninit::<SampleItemC>::uninit(),
>> +//! #     MaybeUninit::<SampleItemC>::uninit(),
>> +//! # ];
>> +//! #
>> +//! # for (i, item) in items.iter_mut().enumerate() {
>> +//! #     let ptr = item.as_mut_ptr();
>> +//! #     // SAFETY: pointers are to allocated test objects with a list_head field.
>> +//! #     unsafe {
>> +//! #         (*ptr).value = i as i32 * 10;
>> +//! #         // addr_of_mut!() computes address of link directly as link is uninitialized.
>> +//! #         init_list_head(core::ptr::addr_of_mut!((*ptr).link));
>> +//! #         bindings::list_add_tail(&mut (*ptr).link, &mut head);
>> +//! #     }
>> +//! # }
>> +//!
>> +//! // Rust wrapper for the C struct.
>> +//! // The list item struct in this example is defined in C code as:
>> +//! //   struct SampleItemC {
>> +//! //       int value;
>> +//! //       struct list_head link;
>> +//! //   };
>> +//! //
>> +//! #[repr(transparent)]
>> +//! pub(crate) struct Item(Opaque<SampleItemC>);
>> +//!
>> +//! impl Item {
>> +//!     pub(crate) fn value(&self) -> i32 {
>> +//!         // SAFETY: `Item` has same layout as `SampleItemC`.
>> +//!         unsafe { (*self.0.get()).value }
>> +//!     }
>> +//! }
>> +//!
>> +//! // Create typed Clist from sentinel head.
>> +//! // SAFETY: head is valid, items are `SampleItemC` with embedded `link` field.
>> +//! let list = unsafe { clist_create!(&mut head, Item, SampleItemC, link) };
>> +//!
>> +//! // Iterate directly over typed items.
>> +//! let mut found_0 = false;
>> +//! let mut found_10 = false;
>> +//! let mut found_20 = false;
>> +//!
>> +//! for item in list.iter() {
>> +//!     let val = item.value();
>> +//!     if val == 0 { found_0 = true; }
>> +//!     if val == 10 { found_10 = true; }
>> +//!     if val == 20 { found_20 = true; }
>> +//! }
>> +//!
>> +//! assert!(found_0 && found_10 && found_20);
>> +//! ```
>> +

[...]

>> +impl<'a> Iterator for ClistHeadIter<'a> {
>> +    type Item = &'a ClistHead;
>> +
>> +    #[inline]
>> +    fn next(&mut self) -> Option<Self::Item> {
>> +        if self.exhausted {
>> +            return None;
>> +        }
>> +
>> +        // Advance to next node.
>> +        self.current_head = self.current_head.next();
>> +
>> +        // Check if we've circled back to the sentinel head.
>> +        if self.current_head == self.list_head {
>> +            self.exhausted = true;
>> +            return None;
>> +        }
>> +
>> +        Some(self.current_head)
>> +    }
>> +}
>> +
>> +impl<'a> FusedIterator for ClistHeadIter<'a> {}
>> +
>> +/// A typed C linked list with a sentinel head.
>> +///
>> +/// A sentinel head represents the entire linked list and can be used for
>> +/// iteration over items of type `T`, it is not associated with a specific item.
>> +///
>> +/// # Invariants
>> +///
>> +/// - `head` is an allocated and valid C `list_head` structure that is the list's sentinel.
>> +/// - `offset` is the byte offset of the `list_head` field within the C struct that `T` wraps.
>> +///
>> +/// # Safety
>> +///
>> +/// - All the list's `list_head` nodes must be allocated and have valid next/prev pointers.
>> +/// - The underlying `list_head` (and entire list) must not be modified by C for the
>> +///   lifetime 'a of `Clist`.
>> +pub struct Clist<'a, T> {
>> +    head: &'a ClistHead,
>> +    offset: usize,
>> +    _phantom: PhantomData<&'a T>,
>> +}
> 
> This discards build-time (const generic) information, and demotes it to 
> runtime (.offset), without any real benefit. I believe it's better to keep
> it as a const generic, like this:
> 
> pub struct Clist<'a, T, const OFFSET: usize> {
>     head: &'a ClistHead,
>     _phantom: PhantomData<&'a T>,
> }
> 
>> +
>> +impl<'a, T> Clist<'a, T> {
> 
> And here, the above becomes:
> 
> impl<'a, T, const OFFSET: usize> Clist<'a, T, OFFSET> {
> 
> ...etc.

It is not ignored, the const-generic part only applies to the constructor method
in my patch. I didn't want to add another argument to the diamond brackets, the
type name looks really ugly then.

The only advantage I think of doing this (inspite of the obvious aesthetic
disadvantage) is that a mutable `Clist` cannot have its offset modified. Let me
see if I can get Alice's suggestion to make it a const in the struct work to
solve that.

[..]
>> +impl<'a, T> FusedIterator for ClistIter<'a, T> {}
>> +
>> +/// Create a C doubly-circular linked list interface `Clist` from a raw `list_head` pointer.
>> +///
>> +/// This macro creates a `Clist<T>` that can iterate over items of type `$rust_type` linked
>> +/// via the `$field` field in the underlying C struct `$c_type`.
>> +///
>> +/// # Arguments
>> +///
>> +/// - `$head`: Raw pointer to the sentinel `list_head` object (`*mut bindings::list_head`).
>> +/// - `$rust_type`: Each item's rust wrapper type.
>> +/// - `$c_type`: Each item's C struct type that contains the embedded `list_head`.
>> +/// - `$field`: The name of the `list_head` field within the C struct.
>> +///
>> +/// # Safety
>> +///
>> +/// The caller must ensure:
>> +/// - `$head` is a valid, initialized sentinel `list_head` pointing to a list that remains
>> +///   unmodified for the lifetime of the rust `Clist`.
>> +/// - The list contains items of type `$c_type` linked via an embedded `$field`.
>> +/// - `$rust_type` is `#[repr(transparent)]` over `$c_type` or has compatible layout.
>> +/// - The macro is called from an unsafe block.
>> +///
>> +/// # Examples
>> +///
>> +/// Refer to the examples in the [crate::clist] module documentation.
>> +#[macro_export]
>> +macro_rules! clist_create {
>> +    ($head:expr, $rust_type:ty, $c_type:ty, $field:ident) => {
>> +        $crate::clist::Clist::<$rust_type>::from_raw_and_offset::<
>> +            { ::core::mem::offset_of!($c_type, $field) },
>> +        >($head)
>> +    };
>> +}
> 
> Unlike the corresponding C container_of() macro, this one here has no
> compile-time verification that the field is actually a list_head.
> 
> How about this, to add that check:
> 
> --- a/rust/kernel/clist.rs
> +++ b/rust/kernel/clist.rs
>  macro_rules! clist_create {
> -    ($head:expr, $rust_type:ty, $c_type:ty, $field:ident) => {
> -        $crate::clist::Clist::<$rust_type>::from_raw_and_offset::<
> +    ($head:expr, $rust_type:ty, $c_type:ty, $field:ident) => {{
> +        // Compile-time check: $field must be a list_head.
> +        const _: () = {
> +            let _check: fn(*const $c_type) -> *const $crate::bindings::list_head =
> +                |p| unsafe { ::core::ptr::addr_of!((*p).$field) };
> +        };
> +        $crate::clist::Clist::<$rust_type, { ::core::mem::offset_of!($c_type, $field) }>::from_raw(
>              $head,
>          )
> -    };
> +    }};
Sure I will play with your suggested snippet and add that, thanks.

 - Joel

Powered by blists - more mailing lists