Add a new module `clist` for working with C's doubly circular linked
lists. Provide low-level iteration over list nodes.

Typed iteration over actual items is provided with a `clist_create`
macro to assist in creation of the `CList` type.

Cc: Nikola Djukic <ndjukic@nvidia.com>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Acked-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
---
 MAINTAINERS              |   7 +
 rust/helpers/helpers.c   |   1 +
 rust/helpers/list.c      |  17 ++
 rust/kernel/ffi/clist.rs | 327 +++++++++++++++++++++++++++++++++++++++
 rust/kernel/ffi/mod.rs   |   2 +
 5 files changed, 354 insertions(+)
 create mode 100644 rust/helpers/list.c
 create mode 100644 rust/kernel/ffi/clist.rs

diff --git a/MAINTAINERS b/MAINTAINERS
index 14b4f9af0e36..4647f4601038 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -23213,6 +23213,13 @@ S:	Maintained
 T:	git https://github.com/Rust-for-Linux/linux.git rust-analyzer-next
 F:	scripts/generate_rust_analyzer.py
 
+RUST TO C LIST INTERFACES
+M:	Joel Fernandes <joelagnelf@nvidia.com>
+M:	Alexandre Courbot <acourbot@nvidia.com>
+L:	rust-for-linux@vger.kernel.org
+S:	Maintained
+F:	rust/kernel/ffi/clist.rs
+
 RXRPC SOCKETS (AF_RXRPC)
 M:	David Howells <dhowells@redhat.com>
 M:	Marc Dionne <marc.dionne@auristor.com>
diff --git a/rust/helpers/helpers.c b/rust/helpers/helpers.c
index a3c42e51f00a..724fcb8240ac 100644
--- a/rust/helpers/helpers.c
+++ b/rust/helpers/helpers.c
@@ -35,6 +35,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..4c1f9c111ec8
--- /dev/null
+++ b/rust/helpers/list.c
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/*
+ * Helpers for C Circular doubly linked list implementation.
+ */
+
+#include <linux/list.h>
+
+__rust_helper void rust_helper_INIT_LIST_HEAD(struct list_head *list)
+{
+	INIT_LIST_HEAD(list);
+}
+
+__rust_helper void rust_helper_list_add_tail(struct list_head *new, struct list_head *head)
+{
+	list_add_tail(new, head);
+}
diff --git a/rust/kernel/ffi/clist.rs b/rust/kernel/ffi/clist.rs
new file mode 100644
index 000000000000..a84f395875dc
--- /dev/null
+++ b/rust/kernel/ffi/clist.rs
@@ -0,0 +1,327 @@
+// SPDX-License-Identifier: GPL-2.0
+
+//! FFI interface for C doubly circular intrusive linked lists.
+//!
+//! This module provides Rust abstractions for iterating over C `list_head`-based
+//! linked lists. It is intended for FFI use-cases where a C subsystem manages a
+//! circular linked list that Rust code needs to read. This is generally required
+//! only for special cases and should be avoided by drivers.
+//!
+//! # Examples
+//!
+//! ```
+//! use kernel::{
+//!     bindings,
+//!     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 struct SampleItemC {
+//! #     pub value: i32,
+//! #     pub link: bindings::list_head,
+//! # }
+//! #
+//! # let mut head = MaybeUninit::<bindings::list_head>::uninit();
+//! #
+//! # let head = head.as_mut_ptr();
+//! # // SAFETY: head and all the items are test objects allocated in this scope.
+//! # unsafe { bindings::INIT_LIST_HEAD(head) };
+//! #
+//! # 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;
+//! #         // &raw mut computes address of link directly as link is uninitialized.
+//! #         bindings::INIT_LIST_HEAD(&raw mut (*ptr).link);
+//! #         bindings::list_add_tail(&mut (*ptr).link, 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 struct Item(Opaque<SampleItemC>);
+//!
+//! impl Item {
+//!     pub 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!(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);
+//! ```
+
+use core::{
+    iter::FusedIterator,
+    marker::PhantomData, //
+};
+
+use crate::{
+    bindings,
+    types::Opaque, //
+};
+
+use pin_init::{
+    pin_data,
+    pin_init,
+    PinInit //
+};
+
+/// FFI wrapper for a C `list_head` object used in intrusive linked lists.
+///
+/// # Invariants
+///
+/// - [`CListHead`] represents an allocated and valid `list_head` structure.
+#[pin_data]
+#[repr(transparent)]
+pub struct CListHead {
+    #[pin]
+    inner: Opaque<bindings::list_head>,
+}
+
+impl CListHead {
+    /// Create a `&CListHead` reference from a raw `list_head` pointer.
+    ///
+    /// # Safety
+    ///
+    /// - `ptr` must be a valid pointer to an allocated and initialized `list_head` structure.
+    /// - `ptr` must remain valid and unmodified for the lifetime `'a`.
+    /// - The list and all linked `list_head` nodes must not be modified by non-Rust code
+    ///   for the lifetime `'a`.
+    #[inline]
+    pub unsafe fn from_raw<'a>(ptr: *mut bindings::list_head) -> &'a Self {
+        // SAFETY:
+        // - [`CListHead`] has same layout as `list_head`.
+        // - `ptr` is valid and unmodified for 'a per caller guarantees.
+        unsafe { &*ptr.cast() }
+    }
+
+    /// Get the raw `list_head` pointer.
+    #[inline]
+    pub fn as_raw(&self) -> *mut bindings::list_head {
+        self.inner.get()
+    }
+
+    /// Get the next [`CListHead`] in the list.
+    #[inline]
+    pub fn next(&self) -> &Self {
+        let raw = self.as_raw();
+        // SAFETY:
+        // - `self.as_raw()` is valid per type invariants.
+        // - The `next` pointer is guaranteed to be non-NULL.
+        unsafe { Self::from_raw((*raw).next) }
+    }
+
+    /// Check if this node is linked in a list (not isolated).
+    #[inline]
+    pub fn is_linked(&self) -> bool {
+        let raw = self.as_raw();
+        // SAFETY: self.as_raw() is valid per type invariants.
+        unsafe { (*raw).next != raw && (*raw).prev != raw }
+    }
+
+    /// Pin-initializer that initializes the list head.
+    pub fn new() -> impl PinInit<Self> {
+        pin_init!(Self {
+            // SAFETY: `INIT_LIST_HEAD` initializes `slot` to a valid empty list.
+            inner <- Opaque::ffi_init(|slot| unsafe { bindings::INIT_LIST_HEAD(slot) }),
+        })
+    }
+}
+
+// SAFETY: [`CListHead`] can be sent to any thread.
+unsafe impl Send for CListHead {}
+
+// SAFETY: [`CListHead`] can be shared among threads as it is not modified
+// by non-Rust code per safety requirements of [`CListHead::from_raw`].
+unsafe impl Sync for CListHead {}
+
+impl PartialEq for CListHead {
+    #[inline]
+    fn eq(&self, other: &Self) -> bool {
+        core::ptr::eq(self, other)
+    }
+}
+
+impl Eq for CListHead {}
+
+/// Low-level iterator over `list_head` nodes.
+///
+/// An iterator used to iterate over a C intrusive linked list (`list_head`). Caller has to
+/// perform conversion of returned [`CListHead`] to an item (using `container_of` macro or similar).
+///
+/// # Invariants
+///
+/// [`CListHeadIter`] is iterating over an allocated, initialized and valid list.
+struct CListHeadIter<'a> {
+    /// Current position in the list.
+    current: &'a CListHead,
+    /// The sentinel head (used to detect end of iteration).
+    sentinel: &'a CListHead,
+}
+
+impl<'a> Iterator for CListHeadIter<'a> {
+    type Item = &'a CListHead;
+
+    #[inline]
+    fn next(&mut self) -> Option<Self::Item> {
+        // Check if we've reached the sentinel (end of list).
+        if self.current == self.sentinel {
+            return None;
+        }
+
+        let item = self.current;
+        self.current = item.next();
+        Some(item)
+    }
+}
+
+impl<'a> FusedIterator for CListHeadIter<'a> {}
+
+/// A typed C linked list with a sentinel head intended for FFI use-cases where
+/// C subsystem manages a linked list that Rust code needs to read. Generally
+/// required only for special cases.
+///
+/// A sentinel head [`ClistHead`] represents the entire linked list and can be used
+/// for iteration over items of type `T`, it is not associated with a specific item.
+///
+/// The const generic `OFFSET` specifies the byte offset of the `list_head` field within
+/// the struct that `T` wraps.
+///
+/// # Invariants
+///
+/// - The [`CListHead`] is an allocated and valid sentinel C `list_head` structure.
+/// - `OFFSET` is the byte offset of the `list_head` field within the struct that `T` wraps.
+/// - All the list's `list_head` nodes are allocated and have valid next/prev pointers.
+#[repr(transparent)]
+pub struct CList<T, const OFFSET: usize>(CListHead, PhantomData<T>);
+
+impl<T, const OFFSET: usize> CList<T, OFFSET> {
+    /// Create a typed [`CList`] reference from a raw sentinel `list_head` pointer.
+    ///
+    /// # Safety
+    ///
+    /// - `ptr` must be a valid pointer to an allocated and initialized `list_head` structure
+    ///   representing a list sentinel.
+    /// - `ptr` must remain valid and unmodified for the lifetime `'a`.
+    /// - The list must contain items where the `list_head` field is at byte offset `OFFSET`.
+    /// - `T` must be `#[repr(transparent)]` over the C struct.
+    #[inline]
+    pub unsafe fn from_raw<'a>(ptr: *mut bindings::list_head) -> &'a Self {
+        // SAFETY:
+        // - [`CList`] has same layout as [`CListHead`] due to repr(transparent).
+        // - Caller guarantees `ptr` is a valid, sentinel `list_head` object.
+        unsafe { &*ptr.cast() }
+    }
+
+    /// Check if the list is empty.
+    #[inline]
+    pub fn is_empty(&self) -> bool {
+        !self.0.is_linked()
+    }
+
+    /// Create an iterator over typed items.
+    #[inline]
+    pub fn iter(&self) -> CListIter<'_, T, OFFSET> {
+        let head = &self.0;
+        CListIter {
+            head_iter: CListHeadIter {
+                current: head.next(),
+                sentinel: head,
+            },
+            _phantom: PhantomData,
+        }
+    }
+}
+
+/// High-level iterator over typed list items.
+pub struct CListIter<'a, T, const OFFSET: usize> {
+    head_iter: CListHeadIter<'a>,
+    _phantom: PhantomData<&'a T>,
+}
+
+impl<'a, T, const OFFSET: usize> Iterator for CListIter<'a, T, OFFSET> {
+    type Item = &'a T;
+
+    fn next(&mut self) -> Option<Self::Item> {
+        let head = self.head_iter.next()?;
+
+        // Convert to item using OFFSET.
+        // SAFETY: `item_ptr` calculation from `OFFSET` (calculated using offset_of!)
+        // is valid per invariants.
+        Some(unsafe { &*head.as_raw().byte_sub(OFFSET).cast::<T>() })
+    }
+}
+
+impl<'a, T, const OFFSET: usize> FusedIterator for CListIter<'a, T, OFFSET> {}
+
+/// Create a C doubly-circular linked list interface `CList` from a raw `list_head` pointer.
+///
+/// This macro creates a `CList<T, OFFSET>` 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
+///
+/// This is an unsafe macro. 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.
+///
+/// # Examples
+///
+/// Refer to the examples in this module's documentation.
+#[macro_export]
+macro_rules! clist_create {
+    ($head:expr, $rust_type:ty, $c_type:ty, $($field:tt).+) => {{
+        // Compile-time check that field path is a list_head.
+        let _: fn(*const $c_type) -> *const $crate::bindings::list_head =
+            |p| &raw const (*p).$($field).+;
+
+        // Calculate offset and create `CList`.
+        const OFFSET: usize = ::core::mem::offset_of!($c_type, $($field).+);
+        $crate::ffi::clist::CList::<$rust_type, OFFSET>::from_raw($head)
+    }};
+}
diff --git a/rust/kernel/ffi/mod.rs b/rust/kernel/ffi/mod.rs
index 7d844e9cb339..8c235ca0d1e3 100644
--- a/rust/kernel/ffi/mod.rs
+++ b/rust/kernel/ffi/mod.rs
@@ -5,3 +5,5 @@
 // Re-export C type definitions from the `ffi` crate so that existing
 // `kernel::ffi::c_int` etc. paths continue to work.
 pub use ::ffi::*;
+
+pub mod clist;
-- 
2.34.1

On Wed, Feb 18, 2026 at 03:55:03PM -0500, Joel Fernandes wrote:
> Add a new module `clist` for working with C's doubly circular linked
> lists. Provide low-level iteration over list nodes.
> 
> Typed iteration over actual items is provided with a `clist_create`
> macro to assist in creation of the `CList` type.
> 
> Cc: Nikola Djukic <ndjukic@nvidia.com>
> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
> Acked-by: Gary Guo <gary@garyguo.net>
> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>

In general this looks like a useful tool to write other abstractions, so
that's good. A few nits below.

Also, I think it would make more sense to split this series into two
with titles like this:

* Add clist helper for writing abstractions using C lists
* Move buddy alloctor one level up

That way, you can tell what the series actually does from its title.
Yes, the 'why' of a series is very important, and must be included in
the cover letter or commit messages, but I think the title of a series
should explain the 'what', not the 'why'.

> +impl CListHead {
> +    /// Create a `&CListHead` reference from a raw `list_head` pointer.
> +    ///
> +    /// # Safety
> +    ///
> +    /// - `ptr` must be a valid pointer to an allocated and initialized `list_head` structure.
> +    /// - `ptr` must remain valid and unmodified for the lifetime `'a`.
> +    /// - The list and all linked `list_head` nodes must not be modified by non-Rust code
> +    ///   for the lifetime `'a`.

I don't think C vs Rust is useful here. What you want is that the list
is not modified by random other code in ways you didn't expect. It
doesn't matter if it's C or Rust code that carries out the illegal
modification.

> +// SAFETY: [`CListHead`] can be sent to any thread.
> +unsafe impl Send for CListHead {}
> +
> +// SAFETY: [`CListHead`] can be shared among threads as it is not modified
> +// by non-Rust code per safety requirements of [`CListHead::from_raw`].
> +unsafe impl Sync for CListHead {}

Same here. If another piece of Rust code modifies the list in parallel
from another thread, you'll have a bad time too. C vs Rust does not
matter.

Alice

Hi Alice,

On 2/21/2026 3:59 AM, Alice Ryhl wrote:
> On Wed, Feb 18, 2026 at 03:55:03PM -0500, Joel Fernandes wrote:
>> Add a new module `clist` for working with C's doubly circular linked
>> lists. Provide low-level iteration over list nodes.
>>
>> Typed iteration over actual items is provided with a `clist_create`
>> macro to assist in creation of the `CList` type.
>>
>> Cc: Nikola Djukic <ndjukic@nvidia.com>
>> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
>> Acked-by: Gary Guo <gary@garyguo.net>
>> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
> 
> In general this looks like a useful tool to write other abstractions, so
> that's good. A few nits below.
> 
> Also, I think it would make more sense to split this series into two
> with titles like this:
> 
> * Add clist helper for writing abstractions using C lists
> * Move buddy alloctor one level up
> 
> That way, you can tell what the series actually does from its title.
> Yes, the 'why' of a series is very important, and must be included in
> the cover letter or commit messages, but I think the title of a series
> should explain the 'what', not the 'why'.

Sure, that makes sense I can move the buddy patches into a different series
indeed.

> 
>> +impl CListHead {
>> +    /// Create a `&CListHead` reference from a raw `list_head` pointer.
>> +    ///
>> +    /// # Safety
>> +    ///
>> +    /// - `ptr` must be a valid pointer to an allocated and initialized `list_head` structure.
>> +    /// - `ptr` must remain valid and unmodified for the lifetime `'a`.
>> +    /// - The list and all linked `list_head` nodes must not be modified by non-Rust code
>> +    ///   for the lifetime `'a`.
> 
> I don't think C vs Rust is useful here. What you want is that the list
> is not modified by random other code in ways you didn't expect. It
> doesn't matter if it's C or Rust code that carries out the illegal
> modification.

Yeah, this is true. I will change it to the following then:

"The list and all linked `list_head` nodes must not be modified from
anywhere for the lifetime `'a`."

> 
>> +// SAFETY: [`CListHead`] can be sent to any thread.
>> +unsafe impl Send for CListHead {}
>> +
>> +// SAFETY: [`CListHead`] can be shared among threads as it is not modified
>> +// by non-Rust code per safety requirements of [`CListHead::from_raw`].
>> +unsafe impl Sync for CListHead {}
> 
> Same here. If another piece of Rust code modifies the list in parallel
> from another thread, you'll have a bad time too. C vs Rust does not
> matter.

Ack, will change it to:
  // SAFETY: [`CListHead`] can be shared among threads as it is
  // read-only per safety requirements of [`CListHead::from_raw`].

thanks,

--
Joel Fernandes

On Sun, Feb 22, 2026 at 07:41:44PM -0500, Joel Fernandes wrote:
> Hi Alice,
> 
> On 2/21/2026 3:59 AM, Alice Ryhl wrote:
> > On Wed, Feb 18, 2026 at 03:55:03PM -0500, Joel Fernandes wrote:
> >> +impl CListHead {
> >> +    /// Create a `&CListHead` reference from a raw `list_head` pointer.
> >> +    ///
> >> +    /// # Safety
> >> +    ///
> >> +    /// - `ptr` must be a valid pointer to an allocated and initialized `list_head` structure.
> >> +    /// - `ptr` must remain valid and unmodified for the lifetime `'a`.
> >> +    /// - The list and all linked `list_head` nodes must not be modified by non-Rust code
> >> +    ///   for the lifetime `'a`.
> > 
> > I don't think C vs Rust is useful here. What you want is that the list
> > is not modified by random other code in ways you didn't expect. It
> > doesn't matter if it's C or Rust code that carries out the illegal
> > modification.
> 
> Yeah, this is true. I will change it to the following then:
> 
> "The list and all linked `list_head` nodes must not be modified from
> anywhere for the lifetime `'a`."

Ok. Perhaps you should say that it must not be modified except through
this CListHead? I guess it depends on whether you want to add methods
for changing the list via this API.

Alice

On 2/23/2026 4:38 AM, Alice Ryhl wrote:
> On Sun, Feb 22, 2026 at 07:41:44PM -0500, Joel Fernandes wrote:
>> Hi Alice,
>>
>> On 2/21/2026 3:59 AM, Alice Ryhl wrote:
>>> On Wed, Feb 18, 2026 at 03:55:03PM -0500, Joel Fernandes wrote:
>>>> +impl CListHead {
>>>> +    /// Create a `&CListHead` reference from a raw `list_head` pointer.
>>>> +    ///
>>>> +    /// # Safety
>>>> +    ///
>>>> +    /// - `ptr` must be a valid pointer to an allocated and initialized `list_head` structure.
>>>> +    /// - `ptr` must remain valid and unmodified for the lifetime `'a`.
>>>> +    /// - The list and all linked `list_head` nodes must not be modified by non-Rust code
>>>> +    ///   for the lifetime `'a`.
>>>
>>> I don't think C vs Rust is useful here. What you want is that the list
>>> is not modified by random other code in ways you didn't expect. It
>>> doesn't matter if it's C or Rust code that carries out the illegal
>>> modification.
>>
>> Yeah, this is true. I will change it to the following then:
>>
>> "The list and all linked `list_head` nodes must not be modified from
>> anywhere for the lifetime `'a`."
> 
> Ok. Perhaps you should say that it must not be modified except through
> this CListHead? I guess it depends on whether you want to add methods
> for changing the list via this API.
> 
At the moment, there isn't a usecase for it but I would predict we would want it
for other such use cases, so yet I will change it to your suggestion to
future-proof it:

"The list and all linked `list_head` nodes must not be modified from
anywhere for the lifetime `'a`, unless done so via any `ClistHead` APIs."

Let me know if it looks good?

thanks,

--
Joel Fernandes

On Thu Feb 19, 2026 at 5:55 AM JST, Joel Fernandes wrote:
> +/// Create a C doubly-circular linked list interface `CList` from a raw `list_head` pointer.
> +///
> +/// This macro creates a `CList<T, OFFSET>` 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
> +///
> +/// This is an unsafe macro. 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.
> +///
> +/// # Examples
> +///
> +/// Refer to the examples in this module's documentation.
> +#[macro_export]
> +macro_rules! clist_create {
> +    ($head:expr, $rust_type:ty, $c_type:ty, $($field:tt).+) => {{
> +        // Compile-time check that field path is a list_head.
> +        let _: fn(*const $c_type) -> *const $crate::bindings::list_head =
> +            |p| &raw const (*p).$($field).+;
> +
> +        // Calculate offset and create `CList`.
> +        const OFFSET: usize = ::core::mem::offset_of!($c_type, $($field).+);
> +        $crate::ffi::clist::CList::<$rust_type, OFFSET>::from_raw($head)
> +    }};
> +}

This uses offset_of! in a way that requires the offset_of_nested
feature, so it doesn't build in rust 1.78.0. The feature is already
added to rust_allowed_features, so I think it's ok to add
#![feature(offset_of_nested)].

Hi Eliot,

On 2/20/2026 3:16 AM, Eliot Courtney wrote:
> On Thu Feb 19, 2026 at 5:55 AM JST, Joel Fernandes wrote:
>> +/// Create a C doubly-circular linked list interface `CList` from a raw `list_head` pointer.
>> +///
>> +/// This macro creates a `CList<T, OFFSET>` 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
>> +///
>> +/// This is an unsafe macro. 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.
>> +///
>> +/// # Examples
>> +///
>> +/// Refer to the examples in this module's documentation.
>> +#[macro_export]
>> +macro_rules! clist_create {
>> +    ($head:expr, $rust_type:ty, $c_type:ty, $($field:tt).+) => {{
>> +        // Compile-time check that field path is a list_head.
>> +        let _: fn(*const $c_type) -> *const $crate::bindings::list_head =
>> +            |p| &raw const (*p).$($field).+;
>> +
>> +        // Calculate offset and create `CList`.
>> +        const OFFSET: usize = ::core::mem::offset_of!($c_type, $($field).+);
>> +        $crate::ffi::clist::CList::<$rust_type, OFFSET>::from_raw($head)
>> +    }};
>> +}
> 
> This uses offset_of! in a way that requires the offset_of_nested
> feature, so it doesn't build in rust 1.78.0. The feature is already
> added to rust_allowed_features, so I think it's ok to add
> #![feature(offset_of_nested)].

Maybe I am missing something, but why should the feature be gated behind
that if all compiler versions (>= 1.78) support it either in a stable way
or via an unstable feature flag?

thanks,

--
Joel Fernandes

On Mon, Feb 23, 2026 at 2:13 AM Joel Fernandes <joelagnelf@nvidia.com> wrote:
>
> Hi Eliot,
>
> On 2/20/2026 3:16 AM, Eliot Courtney wrote:
> > On Thu Feb 19, 2026 at 5:55 AM JST, Joel Fernandes wrote:
> >> +/// Create a C doubly-circular linked list interface `CList` from a raw `list_head` pointer.
> >> +///
> >> +/// This macro creates a `CList<T, OFFSET>` 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
> >> +///
> >> +/// This is an unsafe macro. 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.
> >> +///
> >> +/// # Examples
> >> +///
> >> +/// Refer to the examples in this module's documentation.
> >> +#[macro_export]
> >> +macro_rules! clist_create {
> >> +    ($head:expr, $rust_type:ty, $c_type:ty, $($field:tt).+) => {{
> >> +        // Compile-time check that field path is a list_head.
> >> +        let _: fn(*const $c_type) -> *const $crate::bindings::list_head =
> >> +            |p| &raw const (*p).$($field).+;
> >> +
> >> +        // Calculate offset and create `CList`.
> >> +        const OFFSET: usize = ::core::mem::offset_of!($c_type, $($field).+);
> >> +        $crate::ffi::clist::CList::<$rust_type, OFFSET>::from_raw($head)
> >> +    }};
> >> +}
> >
> > This uses offset_of! in a way that requires the offset_of_nested
> > feature, so it doesn't build in rust 1.78.0. The feature is already
> > added to rust_allowed_features, so I think it's ok to add
> > #![feature(offset_of_nested)].
>
> Maybe I am missing something, but why should the feature be gated behind
> that if all compiler versions (>= 1.78) support it either in a stable way
> or via an unstable feature flag?

The rust_allowed_features list only applies to drivers and such. It
doesn't apply to the Rust crates in the rust/ directory, which need to
use #![feature] annotations manually.

Alice

On 2/24/2026 2:28 AM, Alice Ryhl wrote:
> On Mon, Feb 23, 2026 at 2:13 AM Joel Fernandes <joelagnelf@nvidia.com> wrote:
>>
>> Hi Eliot,
>>
>> On 2/20/2026 3:16 AM, Eliot Courtney wrote:
>>> On Thu Feb 19, 2026 at 5:55 AM JST, Joel Fernandes wrote:
>>>> +/// Create a C doubly-circular linked list interface `CList` from a raw `list_head` pointer.
>>>> +///
>>>> +/// This macro creates a `CList<T, OFFSET>` 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
>>>> +///
>>>> +/// This is an unsafe macro. 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.
>>>> +///
>>>> +/// # Examples
>>>> +///
>>>> +/// Refer to the examples in this module's documentation.
>>>> +#[macro_export]
>>>> +macro_rules! clist_create {
>>>> +    ($head:expr, $rust_type:ty, $c_type:ty, $($field:tt).+) => {{
>>>> +        // Compile-time check that field path is a list_head.
>>>> +        let _: fn(*const $c_type) -> *const $crate::bindings::list_head =
>>>> +            |p| &raw const (*p).$($field).+;
>>>> +
>>>> +        // Calculate offset and create `CList`.
>>>> +        const OFFSET: usize = ::core::mem::offset_of!($c_type, $($field).+);
>>>> +        $crate::ffi::clist::CList::<$rust_type, OFFSET>::from_raw($head)
>>>> +    }};
>>>> +}
>>>
>>> This uses offset_of! in a way that requires the offset_of_nested
>>> feature, so it doesn't build in rust 1.78.0. The feature is already
>>> added to rust_allowed_features, so I think it's ok to add
>>> #![feature(offset_of_nested)].
>>
>> Maybe I am missing something, but why should the feature be gated behind
>> that if all compiler versions (>= 1.78) support it either in a stable way
>> or via an unstable feature flag?
> 
> The rust_allowed_features list only applies to drivers and such. It
> doesn't apply to the Rust crates in the rust/ directory, which need to
> use #![feature] annotations manually.

Ah fun! Ok, I will add it in in. :)

thanks,

--
Joel Fernandes

On Tue, Feb 24, 2026 at 5:00 PM Joel Fernandes <joelagnelf@nvidia.com> wrote:
>
> Ah fun! Ok, I will add it in in. :)

To clarify further, the reason is that the crates in `rust/` may (and
do) use more features (which still need justification), but the rest
of the kernel is restricted to those in that "allowed" list only.

  https://rust-for-linux.com/unstable-features#usage-in-the-kernel

Cheers,
Miguel

On Mon Feb 23, 2026 at 10:13 AM JST, Joel Fernandes wrote:
>>> +macro_rules! clist_create {
>>> +    ($head:expr, $rust_type:ty, $c_type:ty, $($field:tt).+) => {{
>>> +        // Compile-time check that field path is a list_head.
>>> +        let _: fn(*const $c_type) -> *const $crate::bindings::list_head =
>>> +            |p| &raw const (*p).$($field).+;
>>> +
>>> +        // Calculate offset and create `CList`.
>>> +        const OFFSET: usize = ::core::mem::offset_of!($c_type, $($field).+);
>>> +        $crate::ffi::clist::CList::<$rust_type, OFFSET>::from_raw($head)
>>> +    }};
>>> +}
>> 
>> This uses offset_of! in a way that requires the offset_of_nested
>> feature, so it doesn't build in rust 1.78.0. The feature is already
>> added to rust_allowed_features, so I think it's ok to add
>> #![feature(offset_of_nested)].
>
> Maybe I am missing something, but why should the feature be gated behind
> that if all compiler versions (>= 1.78) support it either in a stable way
> or via an unstable feature flag?

I think that's why it's in rust_allowed_features. IIUC that's where we
put unstable features that are stable enough in all supported compiler
versions to be used.

But, rust_allowed_features doesn't apply to the code here, so you'd have
to add an allow to rust/kernel/lib.rs.

On Wed Feb 18, 2026 at 9:55 PM CET, Joel Fernandes wrote:
> +RUST TO C LIST INTERFACES

Maybe this should just be "RUST [FFI]" instead (in case Alex and you want to
sign up for looking after FFI helper infrastructure in general)?

> +M:	Joel Fernandes <joelagnelf@nvidia.com>
> +M:	Alexandre Courbot <acourbot@nvidia.com>
> +L:	rust-for-linux@vger.kernel.org
> +S:	Maintained
> +F:	rust/kernel/ffi/clist.rs

<snip>

> diff --git a/rust/kernel/ffi/clist.rs b/rust/kernel/ffi/clist.rs
> new file mode 100644
> index 000000000000..a84f395875dc
> --- /dev/null
> +++ b/rust/kernel/ffi/clist.rs
> @@ -0,0 +1,327 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +//! FFI interface for C doubly circular intrusive linked lists.
> +//!
> +//! This module provides Rust abstractions for iterating over C `list_head`-based
> +//! linked lists. It is intended for FFI use-cases where a C subsystem manages a
> +//! circular linked list that Rust code needs to read. This is generally required
> +//! only for special cases and should be avoided by drivers.

Maybe generalize the statement a bit and say that this should only be used for
cases where C and Rust code share direct access to the same linked list through
an FFI interface.

Additionally, add a separate note that this *must not* be used by Rust
components that just aim for a linked list primitive and instead refer to the
Rust linked list implementation with an intra-doc link.

> +//!
> +//! # Examples
> +//!
> +//! ```
> +//! use kernel::{
> +//!     bindings,
> +//!     clist_create,
> +//!     types::Opaque, //

Examples don't necessarily need '//' at the end, as they are not automatically
formatted anyways.

(I hope that we will have a solution for import formatting before rustfmt
supports doc-comments. :)

> +//! };
> +//! # // 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 struct SampleItemC {
> +//! #     pub value: i32,
> +//! #     pub link: bindings::list_head,
> +//! # }
> +//! #
> +//! # let mut head = MaybeUninit::<bindings::list_head>::uninit();
> +//! #
> +//! # let head = head.as_mut_ptr();
> +//! # // SAFETY: head and all the items are test objects allocated in this scope.
> +//! # unsafe { bindings::INIT_LIST_HEAD(head) };
> +//! #
> +//! # 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 {

I understand that this is just setup code for a doc-test, but I still think we
should hold it to the same standards, i.e. let's separate the different unsafe
calls into their own unsafe blocks and add proper safety comments.

> +//! #         (*ptr).value = i as i32 * 10;
> +//! #         // &raw mut computes address of link directly as link is uninitialized.
> +//! #         bindings::INIT_LIST_HEAD(&raw mut (*ptr).link);
> +//! #         bindings::list_add_tail(&mut (*ptr).link, head);
> +//! #     }
> +//! # }

<snip>

> +use pin_init::{
> +    pin_data,
> +    pin_init,
> +    PinInit //

Should be 'PinInit, //'.

> +};
> +
> +/// FFI wrapper for a C `list_head` object used in intrusive linked lists.
> +///
> +/// # Invariants
> +///
> +/// - [`CListHead`] represents an allocated and valid `list_head` structure.

What does "allocated" mean in this context? (Dynamic allocations, stack, .data
section of the binary, any of those?)

In case of the latter, I'd just remove "allocated".

> +#[pin_data]
> +#[repr(transparent)]
> +pub struct CListHead {
> +    #[pin]
> +    inner: Opaque<bindings::list_head>,
> +}
> +
> +impl CListHead {
> +    /// Create a `&CListHead` reference from a raw `list_head` pointer.
> +    ///
> +    /// # Safety
> +    ///
> +    /// - `ptr` must be a valid pointer to an allocated and initialized `list_head` structure.

Same here, what exactly is meant by "allocated"?

> +    /// - `ptr` must remain valid and unmodified for the lifetime `'a`.
> +    /// - The list and all linked `list_head` nodes must not be modified by non-Rust code
> +    ///   for the lifetime `'a`.

This is a bit vague I think, concurrent modifications of (other) Rust code are
not OK either.

> +    #[inline]
> +    pub unsafe fn from_raw<'a>(ptr: *mut bindings::list_head) -> &'a Self {
> +        // SAFETY:
> +        // - [`CListHead`] has same layout as `list_head`.
> +        // - `ptr` is valid and unmodified for 'a per caller guarantees.
> +        unsafe { &*ptr.cast() }
> +    }
> +
> +    /// Get the raw `list_head` pointer.
> +    #[inline]
> +    pub fn as_raw(&self) -> *mut bindings::list_head {
> +        self.inner.get()
> +    }
> +
> +    /// Get the next [`CListHead`] in the list.
> +    #[inline]
> +    pub fn next(&self) -> &Self {
> +        let raw = self.as_raw();
> +        // SAFETY:
> +        // - `self.as_raw()` is valid per type invariants.
> +        // - The `next` pointer is guaranteed to be non-NULL.

I'm not sure whether "valid" in the type invariant implies that the struct
list_head is initialized. From a language point of view it is also valid if the
pointers are NULL.

So, I think the invariant (and the safety requirements of from_raw()) have to
ensure that the struct list_head is initialized in the sense of
INIT_LIST_HEAD().

> +        unsafe { Self::from_raw((*raw).next) }
> +    }

<snip>

> +/// A typed C linked list with a sentinel head intended for FFI use-cases where
> +/// C subsystem manages a linked list that Rust code needs to read. Generally
> +/// required only for special cases.
> +///
> +/// A sentinel head [`ClistHead`] represents the entire linked list and can be used
> +/// for iteration over items of type `T`, it is not associated with a specific item.
> +///
> +/// The const generic `OFFSET` specifies the byte offset of the `list_head` field within
> +/// the struct that `T` wraps.
> +///
> +/// # Invariants
> +///
> +/// - The [`CListHead`] is an allocated and valid sentinel C `list_head` structure.
> +/// - `OFFSET` is the byte offset of the `list_head` field within the struct that `T` wraps.
> +/// - All the list's `list_head` nodes are allocated and have valid next/prev pointers.
> +#[repr(transparent)]
> +pub struct CList<T, const OFFSET: usize>(CListHead, PhantomData<T>);
> +
> +impl<T, const OFFSET: usize> CList<T, OFFSET> {
> +    /// Create a typed [`CList`] reference from a raw sentinel `list_head` pointer.
> +    ///
> +    /// # Safety
> +    ///
> +    /// - `ptr` must be a valid pointer to an allocated and initialized `list_head` structure
> +    ///   representing a list sentinel.
> +    /// - `ptr` must remain valid and unmodified for the lifetime `'a`.
> +    /// - The list must contain items where the `list_head` field is at byte offset `OFFSET`.
> +    /// - `T` must be `#[repr(transparent)]` over the C struct.
> +    #[inline]
> +    pub unsafe fn from_raw<'a>(ptr: *mut bindings::list_head) -> &'a Self {
> +        // SAFETY:
> +        // - [`CList`] has same layout as [`CListHead`] due to repr(transparent).
> +        // - Caller guarantees `ptr` is a valid, sentinel `list_head` object.
> +        unsafe { &*ptr.cast() }
> +    }

Comments from CListHead also apply here.

> +/// Create a C doubly-circular linked list interface `CList` from a raw `list_head` pointer.
> +///
> +/// This macro creates a `CList<T, OFFSET>` 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
> +///
> +/// This is an unsafe macro. The caller must ensure:

Given that, we should probably use the same (or a similar) trick as in [1].

[1] https://rust.docs.kernel.org/src/kernel/device.rs.html#665-688

> +///
> +/// - `$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.
> +///
> +/// # Examples
> +///
> +/// Refer to the examples in this module's documentation.
> +#[macro_export]
> +macro_rules! clist_create {
> +    ($head:expr, $rust_type:ty, $c_type:ty, $($field:tt).+) => {{
> +        // Compile-time check that field path is a list_head.
> +        let _: fn(*const $c_type) -> *const $crate::bindings::list_head =
> +            |p| &raw const (*p).$($field).+;
> +
> +        // Calculate offset and create `CList`.
> +        const OFFSET: usize = ::core::mem::offset_of!($c_type, $($field).+);
> +        $crate::ffi::clist::CList::<$rust_type, OFFSET>::from_raw($head)
> +    }};
> +}

On 2026-02-19 11:21, Danilo Krummrich wrote:
> 
> Examples don't necessarily need '//' at the end, as they are not 
> automatically
> formatted anyways.
> 
> (I hope that we will have a solution for import formatting before 
> rustfmt
> supports doc-comments. :)

There is format_code_in_doc_comments option in rustfmt, unfortunately 
it's unstable.

Best,
Gary

On Wed Feb 18, 2026 at 9:55 PM CET, Joel Fernandes wrote:
> Add a new module `clist` for working with C's doubly circular linked
> lists. Provide low-level iteration over list nodes.
>
> Typed iteration over actual items is provided with a `clist_create`
> macro to assist in creation of the `CList` type.
>
> Cc: Nikola Djukic <ndjukic@nvidia.com>
> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
> Acked-by: Gary Guo <gary@garyguo.net>
> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>

For reference: https://lore.kernel.org/rust-for-linux/DGIIMT4F1GWA.12UFBEUAC80VW@nvidia.com/

On Thu Feb 19, 2026 at 5:55 AM JST, Joel Fernandes wrote:
<snip>
> +use core::{
> +    iter::FusedIterator,
> +    marker::PhantomData, //
> +};
> +
> +use crate::{
> +    bindings,
> +    types::Opaque, //
> +};
> +
> +use pin_init::{
> +    pin_data,
> +    pin_init,
> +    PinInit //

`rustfmt` fixed this to

    PinInit, //

<snip>
> +impl<'a> FusedIterator for CListHeadIter<'a> {}
> +
> +/// A typed C linked list with a sentinel head intended for FFI use-cases where
> +/// C subsystem manages a linked list that Rust code needs to read. Generally
> +/// required only for special cases.
> +///
> +/// A sentinel head [`ClistHead`] represents the entire linked list and can be used

Typo: `CListHead` (rustdoc complained about this).