* Re: [PATCH v13 1/1] rust: interop: Add list module for C linked list interface
2026-03-17 20:17 ` [PATCH v13 1/1] " Joel Fernandes
@ 2026-03-17 20:18 ` Joel Fernandes
2026-03-17 20:20 ` Danilo Krummrich
2026-03-18 8:59 ` Alice Ryhl
2026-03-18 9:10 ` Alice Ryhl
` (2 subsequent siblings)
3 siblings, 2 replies; 32+ messages in thread
From: Joel Fernandes @ 2026-03-17 20:18 UTC (permalink / raw)
To: linux-kernel
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Alex Gaynor, Danilo Krummrich, Dave Airlie, David Airlie,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Simona Vetter, Daniel Almeida, Koen Koning, Nikola Djukic,
Alexandre Courbot, Philipp Stanner, Elle Rhumsaa, Jonathan Corbet,
Alex Deucher, Christian König, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellström,
Helge Deller, John Hubbard, Alistair Popple, Timur Tabi,
Edwin Peer, Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh,
alexeyi, Eliot Courtney, dri-devel, rust-for-linux, linux-doc,
amd-gfx, intel-gfx, intel-xe, linux-fbdev
On 3/17/2026 4:17 PM, Joel Fernandes wrote:
> Add a new module `kernel::interop::list` 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>
> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
> Acked-by: Alexandre Courbot <acourbot@nvidia.com>
> Acked-by: Gary Guo <gary@garyguo.net>
> Acked-by: Miguel Ojeda <ojeda@kernel.org>
> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
> ---
> MAINTAINERS | 8 +
> rust/helpers/helpers.c | 1 +
> rust/helpers/list.c | 17 ++
> rust/kernel/interop.rs | 9 +
> rust/kernel/interop/list.rs | 342 ++++++++++++++++++++++++++++++++++++
> rust/kernel/lib.rs | 2 +
> 6 files changed, 379 insertions(+)
> create mode 100644 rust/helpers/list.c
> create mode 100644 rust/kernel/interop.rs
> create mode 100644 rust/kernel/interop/list.rs
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4bd6b538a51f..e847099efcc2 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -23251,6 +23251,14 @@ T: git https://github.com/Rust-for-Linux/linux.git alloc-next
> F: rust/kernel/alloc.rs
> F: rust/kernel/alloc/
>
> +RUST [INTEROP]
> +M: Joel Fernandes <joelagnelf@nvidia.com>
> +M: Alexandre Courbot <acourbot@nvidia.com>
> +L: rust-for-linux@vger.kernel.org
> +S: Maintained
> +T: git https://github.com/Rust-for-Linux/linux.git interop-next
> +F: rust/kernel/interop/
Sorry, I forgot to add an additional F: for the rust/kernel/interop.rs file.
Danilo/Miguel, do you mind adding this when applying?
thanks,
--
Joel Fernandes
> +
> RUST [NUM]
> M: Alexandre Courbot <acourbot@nvidia.com>
> R: Yury Norov <yury.norov@gmail.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..18095a5593c5
> --- /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/interop.rs b/rust/kernel/interop.rs
> new file mode 100644
> index 000000000000..b88140cf76dc
> --- /dev/null
> +++ b/rust/kernel/interop.rs
> @@ -0,0 +1,9 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +//! Infrastructure for interfacing Rust code with C kernel subsystems.
> +//!
> +//! This module is intended for low-level, unsafe Rust infrastructure code
> +//! that interoperates between Rust and C. It is NOT for use directly in
> +//! Rust drivers.
> +
> +pub mod list;
> diff --git a/rust/kernel/interop/list.rs b/rust/kernel/interop/list.rs
> new file mode 100644
> index 000000000000..328f6b0de2ce
> --- /dev/null
> +++ b/rust/kernel/interop/list.rs
> @@ -0,0 +1,342 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +//! Rust interface for C doubly circular intrusive linked lists.
> +//!
> +//! This module provides Rust abstractions for iterating over C `list_head`-based
> +//! linked lists. It should only be used for cases where C and Rust code share
> +//! direct access to the same linked list through a C interop interface.
> +//!
> +//! Note: This *must not* be used by Rust components that just need a linked list
> +//! primitive. Use [`kernel::list::List`] instead.
> +//!
> +//! # 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: `ptr` points to a valid `MaybeUninit<SampleItemC>`.
> +//! # unsafe { (*ptr).value = i as i32 * 10 };
> +//! # // SAFETY: `&raw mut` creates a pointer valid for `INIT_LIST_HEAD`.
> +//! # unsafe { bindings::INIT_LIST_HEAD(&raw mut (*ptr).link) };
> +//! # // SAFETY: `link` was just initialized and `head` is a valid list head.
> +//! # unsafe { 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:
> +//! ///
> +//! /// ```c
> +//! /// 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 and initialized, items are `SampleItemC` with
> +//! // embedded `link` field, and `Item` is `#[repr(transparent)]` over `SampleItemC`.
> +//! let list = clist_create!(unsafe { 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
> +///
> +/// - The underlying `list_head` is initialized with valid non-`NULL` `next`/`prev` pointers.
> +#[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 initialized `list_head` (e.g. via
> + /// `INIT_LIST_HEAD()`), with valid non-`NULL` `next`/`prev` pointers.
> + /// - `ptr` must remain valid for the lifetime `'a`.
> + /// - 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.
> + #[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 and initialized per type invariants.
> + // - The `next` pointer is valid and non-`NULL` per type invariants
> + // (initialized via `INIT_LIST_HEAD()` or equivalent).
> + 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: `list_head` contains no thread-bound state; it only holds
> +// `next`/`prev` pointers.
> +unsafe impl Send for CListHead {}
> +
> +// SAFETY: `CListHead` can be shared among threads as modifications are
> +// not allowed at the moment.
> +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`] or similar).
> +///
> +/// # Invariants
> +///
> +/// `current` and `sentinel` are valid references into an initialized linked 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 sentinel [`CListHead`] has valid non-`NULL` `next`/`prev` pointers.
> +/// - `OFFSET` is the byte offset of the `list_head` field within the struct that `T` wraps.
> +/// - All the list's `list_head` nodes have valid non-`NULL` `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 initialized sentinel `list_head` (e.g. via
> + /// `INIT_LIST_HEAD()`), with valid non-`NULL` `next`/`prev` pointers.
> + /// - `ptr` must remain valid for the lifetime `'a`.
> + /// - The list and all linked nodes must not be concurrently modified 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;
> +
> + #[inline]
> + fn next(&mut self) -> Option<Self::Item> {
> + let head = self.head_iter.next()?;
> +
> + // Convert to item using `OFFSET`.
> + //
> + // SAFETY: The pointer calculation is valid because `OFFSET` is derived
> + // from `offset_of!` per type 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
> +///
> +/// The caller must ensure:
> +///
> +/// - `$head` is a valid, initialized sentinel `list_head` (e.g. via `INIT_LIST_HEAD()`)
> +/// pointing to a list that is not concurrently modified for the lifetime of the [`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 the [`crate::interop::list`] module documentation.
> +#[macro_export]
> +macro_rules! clist_create {
> + (unsafe { $head:ident, $rust_type:ty, $c_type:ty, $($field:tt).+ }) => {{
> + // Compile-time check that field path is a `list_head`.
> + // SAFETY: `p` is a valid pointer to `$c_type`.
> + let _: fn(*const $c_type) -> *const $crate::bindings::list_head =
> + |p| unsafe { &raw const (*p).$($field).+ };
> +
> + // Calculate offset and create `CList`.
> + const OFFSET: usize = ::core::mem::offset_of!($c_type, $($field).+);
> + // SAFETY: The caller of this macro is responsible for ensuring safety.
> + unsafe { $crate::interop::list::CList::<$rust_type, OFFSET>::from_raw($head) }
> + }};
> +}
> diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
> index d93292d47420..bdcf632050ee 100644
> --- a/rust/kernel/lib.rs
> +++ b/rust/kernel/lib.rs
> @@ -29,6 +29,7 @@
> #![feature(lint_reasons)]
> //
> // Stable since Rust 1.82.0.
> +#![feature(offset_of_nested)]
> #![feature(raw_ref_op)]
> //
> // Stable since Rust 1.83.0.
> @@ -107,6 +108,7 @@
> #[doc(hidden)]
> pub mod impl_flags;
> pub mod init;
> +pub mod interop;
> pub mod io;
> pub mod ioctl;
> pub mod iommu;
--
Joel Fernandes
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH v13 1/1] rust: interop: Add list module for C linked list interface
2026-03-17 20:18 ` Joel Fernandes
@ 2026-03-17 20:20 ` Danilo Krummrich
2026-03-17 20:27 ` Joel Fernandes
2026-03-18 8:59 ` Alice Ryhl
1 sibling, 1 reply; 32+ messages in thread
From: Danilo Krummrich @ 2026-03-17 20:20 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Alex Gaynor, Dave Airlie, David Airlie,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Simona Vetter, Daniel Almeida, Koen Koning, Nikola Djukic,
Alexandre Courbot, Philipp Stanner, Elle Rhumsaa, Jonathan Corbet,
Alex Deucher, Christian König, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellström,
Helge Deller, John Hubbard, Alistair Popple, Timur Tabi,
Edwin Peer, Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh,
alexeyi, Eliot Courtney, dri-devel, rust-for-linux, linux-doc,
amd-gfx, intel-gfx, intel-xe, linux-fbdev
On Tue Mar 17, 2026 at 9:18 PM CET, Joel Fernandes wrote:
> Sorry, I forgot to add an additional F: for the rust/kernel/interop.rs file.
> Danilo/Miguel, do you mind adding this when applying?
I can add it, all good.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v13 1/1] rust: interop: Add list module for C linked list interface
2026-03-17 20:20 ` Danilo Krummrich
@ 2026-03-17 20:27 ` Joel Fernandes
0 siblings, 0 replies; 32+ messages in thread
From: Joel Fernandes @ 2026-03-17 20:27 UTC (permalink / raw)
To: Danilo Krummrich
Cc: linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Alex Gaynor, Dave Airlie, David Airlie,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Simona Vetter, Daniel Almeida, Koen Koning, Nikola Djukic,
Alexandre Courbot, Philipp Stanner, Elle Rhumsaa, Jonathan Corbet,
Alex Deucher, Christian König, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellström,
Helge Deller, John Hubbard, Alistair Popple, Timur Tabi,
Edwin Peer, Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh,
alexeyi, Eliot Courtney, dri-devel, rust-for-linux, linux-doc,
amd-gfx, intel-gfx, intel-xe, linux-fbdev
On 3/17/2026 4:20 PM, Danilo Krummrich wrote:
> On Tue Mar 17, 2026 at 9:18 PM CET, Joel Fernandes wrote:
>> Sorry, I forgot to add an additional F: for the rust/kernel/interop.rs file.
>> Danilo/Miguel, do you mind adding this when applying?
>
> I can add it, all good.
Thanks, Danilo!
--
Joel Fernandes
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v13 1/1] rust: interop: Add list module for C linked list interface
2026-03-17 20:18 ` Joel Fernandes
2026-03-17 20:20 ` Danilo Krummrich
@ 2026-03-18 8:59 ` Alice Ryhl
2026-03-18 10:53 ` Alexandre Courbot
2026-03-18 13:31 ` Gary Guo
1 sibling, 2 replies; 32+ messages in thread
From: Alice Ryhl @ 2026-03-18 8:59 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, Alex Gaynor, Danilo Krummrich, Dave Airlie,
David Airlie, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Simona Vetter, Daniel Almeida, Koen Koning, Nikola Djukic,
Alexandre Courbot, Philipp Stanner, Elle Rhumsaa, Jonathan Corbet,
Alex Deucher, Christian König, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellström,
Helge Deller, John Hubbard, Alistair Popple, Timur Tabi,
Edwin Peer, Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh,
alexeyi, Eliot Courtney, dri-devel, rust-for-linux, linux-doc,
amd-gfx, intel-gfx, intel-xe, linux-fbdev
On Tue, Mar 17, 2026 at 04:18:46PM -0400, Joel Fernandes wrote:
>
>
> On 3/17/2026 4:17 PM, Joel Fernandes wrote:
> > Add a new module `kernel::interop::list` 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>
> > Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
> > Acked-by: Alexandre Courbot <acourbot@nvidia.com>
> > Acked-by: Gary Guo <gary@garyguo.net>
> > Acked-by: Miguel Ojeda <ojeda@kernel.org>
> > Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
> > ---
> > MAINTAINERS | 8 +
> > rust/helpers/helpers.c | 1 +
> > rust/helpers/list.c | 17 ++
> > rust/kernel/interop.rs | 9 +
> > rust/kernel/interop/list.rs | 342 ++++++++++++++++++++++++++++++++++++
> > rust/kernel/lib.rs | 2 +
> > 6 files changed, 379 insertions(+)
> > create mode 100644 rust/helpers/list.c
> > create mode 100644 rust/kernel/interop.rs
> > create mode 100644 rust/kernel/interop/list.rs
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 4bd6b538a51f..e847099efcc2 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -23251,6 +23251,14 @@ T: git https://github.com/Rust-for-Linux/linux.git alloc-next
> > F: rust/kernel/alloc.rs
> > F: rust/kernel/alloc/
> >
> > +RUST [INTEROP]
> > +M: Joel Fernandes <joelagnelf@nvidia.com>
> > +M: Alexandre Courbot <acourbot@nvidia.com>
> > +L: rust-for-linux@vger.kernel.org
> > +S: Maintained
> > +T: git https://github.com/Rust-for-Linux/linux.git interop-next
> > +F: rust/kernel/interop/
>
> Sorry, I forgot to add an additional F: for the rust/kernel/interop.rs file.
> Danilo/Miguel, do you mind adding this when applying?
I think you should consider a mod.rs file to avoid this. It's tiny, and
just re-exports submodules, so I don't think the "mod.rs name in file
view" concern is that big, and IMO having files related to interop/
inside the directory is much better than having them outside.
Alice
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v13 1/1] rust: interop: Add list module for C linked list interface
2026-03-18 8:59 ` Alice Ryhl
@ 2026-03-18 10:53 ` Alexandre Courbot
2026-03-18 10:59 ` Alice Ryhl
2026-03-18 14:21 ` Miguel Ojeda
2026-03-18 13:31 ` Gary Guo
1 sibling, 2 replies; 32+ messages in thread
From: Alexandre Courbot @ 2026-03-18 10:53 UTC (permalink / raw)
To: Alice Ryhl
Cc: Joel Fernandes, linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, Alex Gaynor, Danilo Krummrich, Dave Airlie,
David Airlie, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Simona Vetter, Daniel Almeida, Koen Koning, Nikola Djukic,
Philipp Stanner, Elle Rhumsaa, Jonathan Corbet, Alex Deucher,
Christian König, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Huang Rui, Matthew Auld, Matthew Brost,
Lucas De Marchi, Thomas Hellström, Helge Deller,
John Hubbard, Alistair Popple, Timur Tabi, Edwin Peer,
Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh, alexeyi,
Eliot Courtney, dri-devel, rust-for-linux, linux-doc, amd-gfx,
intel-gfx, intel-xe, linux-fbdev
On Wed Mar 18, 2026 at 5:59 PM JST, Alice Ryhl wrote:
> On Tue, Mar 17, 2026 at 04:18:46PM -0400, Joel Fernandes wrote:
>>
>>
>> On 3/17/2026 4:17 PM, Joel Fernandes wrote:
>> > Add a new module `kernel::interop::list` 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>
>> > Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
>> > Acked-by: Alexandre Courbot <acourbot@nvidia.com>
>> > Acked-by: Gary Guo <gary@garyguo.net>
>> > Acked-by: Miguel Ojeda <ojeda@kernel.org>
>> > Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
>> > ---
>> > MAINTAINERS | 8 +
>> > rust/helpers/helpers.c | 1 +
>> > rust/helpers/list.c | 17 ++
>> > rust/kernel/interop.rs | 9 +
>> > rust/kernel/interop/list.rs | 342 ++++++++++++++++++++++++++++++++++++
>> > rust/kernel/lib.rs | 2 +
>> > 6 files changed, 379 insertions(+)
>> > create mode 100644 rust/helpers/list.c
>> > create mode 100644 rust/kernel/interop.rs
>> > create mode 100644 rust/kernel/interop/list.rs
>> >
>> > diff --git a/MAINTAINERS b/MAINTAINERS
>> > index 4bd6b538a51f..e847099efcc2 100644
>> > --- a/MAINTAINERS
>> > +++ b/MAINTAINERS
>> > @@ -23251,6 +23251,14 @@ T: git https://github.com/Rust-for-Linux/linux.git alloc-next
>> > F: rust/kernel/alloc.rs
>> > F: rust/kernel/alloc/
>> >
>> > +RUST [INTEROP]
>> > +M: Joel Fernandes <joelagnelf@nvidia.com>
>> > +M: Alexandre Courbot <acourbot@nvidia.com>
>> > +L: rust-for-linux@vger.kernel.org
>> > +S: Maintained
>> > +T: git https://github.com/Rust-for-Linux/linux.git interop-next
>> > +F: rust/kernel/interop/
>>
>> Sorry, I forgot to add an additional F: for the rust/kernel/interop.rs file.
>> Danilo/Miguel, do you mind adding this when applying?
>
> I think you should consider a mod.rs file to avoid this. It's tiny, and
> just re-exports submodules, so I don't think the "mod.rs name in file
> view" concern is that big, and IMO having files related to interop/
> inside the directory is much better than having them outside.
Ah, so there is a rationale for using a `mod.rs` file after all. What
are the project-wide guidelines re: `foo.rs` vs `foo/mod.rs`?
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v13 1/1] rust: interop: Add list module for C linked list interface
2026-03-18 10:53 ` Alexandre Courbot
@ 2026-03-18 10:59 ` Alice Ryhl
2026-03-18 14:30 ` Miguel Ojeda
2026-03-18 14:21 ` Miguel Ojeda
1 sibling, 1 reply; 32+ messages in thread
From: Alice Ryhl @ 2026-03-18 10:59 UTC (permalink / raw)
To: Alexandre Courbot
Cc: Joel Fernandes, linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, Alex Gaynor, Danilo Krummrich, Dave Airlie,
David Airlie, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Simona Vetter, Daniel Almeida, Koen Koning, Nikola Djukic,
Philipp Stanner, Elle Rhumsaa, Jonathan Corbet, Alex Deucher,
Christian König, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Huang Rui, Matthew Auld, Matthew Brost,
Lucas De Marchi, Thomas Hellström, Helge Deller,
John Hubbard, Alistair Popple, Timur Tabi, Edwin Peer,
Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh, alexeyi,
Eliot Courtney, dri-devel, rust-for-linux, linux-doc, amd-gfx,
intel-gfx, intel-xe, linux-fbdev
On Wed, Mar 18, 2026 at 11:53 AM Alexandre Courbot <acourbot@nvidia.com> wrote:
>
> On Wed Mar 18, 2026 at 5:59 PM JST, Alice Ryhl wrote:
> > On Tue, Mar 17, 2026 at 04:18:46PM -0400, Joel Fernandes wrote:
> >>
> >>
> >> On 3/17/2026 4:17 PM, Joel Fernandes wrote:
> >> > Add a new module `kernel::interop::list` 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>
> >> > Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
> >> > Acked-by: Alexandre Courbot <acourbot@nvidia.com>
> >> > Acked-by: Gary Guo <gary@garyguo.net>
> >> > Acked-by: Miguel Ojeda <ojeda@kernel.org>
> >> > Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
> >> > ---
> >> > MAINTAINERS | 8 +
> >> > rust/helpers/helpers.c | 1 +
> >> > rust/helpers/list.c | 17 ++
> >> > rust/kernel/interop.rs | 9 +
> >> > rust/kernel/interop/list.rs | 342 ++++++++++++++++++++++++++++++++++++
> >> > rust/kernel/lib.rs | 2 +
> >> > 6 files changed, 379 insertions(+)
> >> > create mode 100644 rust/helpers/list.c
> >> > create mode 100644 rust/kernel/interop.rs
> >> > create mode 100644 rust/kernel/interop/list.rs
> >> >
> >> > diff --git a/MAINTAINERS b/MAINTAINERS
> >> > index 4bd6b538a51f..e847099efcc2 100644
> >> > --- a/MAINTAINERS
> >> > +++ b/MAINTAINERS
> >> > @@ -23251,6 +23251,14 @@ T: git https://github.com/Rust-for-Linux/linux.git alloc-next
> >> > F: rust/kernel/alloc.rs
> >> > F: rust/kernel/alloc/
> >> >
> >> > +RUST [INTEROP]
> >> > +M: Joel Fernandes <joelagnelf@nvidia.com>
> >> > +M: Alexandre Courbot <acourbot@nvidia.com>
> >> > +L: rust-for-linux@vger.kernel.org
> >> > +S: Maintained
> >> > +T: git https://github.com/Rust-for-Linux/linux.git interop-next
> >> > +F: rust/kernel/interop/
> >>
> >> Sorry, I forgot to add an additional F: for the rust/kernel/interop.rs file.
> >> Danilo/Miguel, do you mind adding this when applying?
> >
> > I think you should consider a mod.rs file to avoid this. It's tiny, and
> > just re-exports submodules, so I don't think the "mod.rs name in file
> > view" concern is that big, and IMO having files related to interop/
> > inside the directory is much better than having them outside.
>
> Ah, so there is a rationale for using a `mod.rs` file after all. What
> are the project-wide guidelines re: `foo.rs` vs `foo/mod.rs`?
I'm not sure we have discussed it in detail yet. Both are used in-tree.
Alice
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v13 1/1] rust: interop: Add list module for C linked list interface
2026-03-18 10:59 ` Alice Ryhl
@ 2026-03-18 14:30 ` Miguel Ojeda
0 siblings, 0 replies; 32+ messages in thread
From: Miguel Ojeda @ 2026-03-18 14:30 UTC (permalink / raw)
To: Alice Ryhl
Cc: Alexandre Courbot, Joel Fernandes, linux-kernel, Miguel Ojeda,
Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Andreas Hindborg, Trevor Gross, Alex Gaynor, Danilo Krummrich,
Dave Airlie, David Airlie, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Simona Vetter, Daniel Almeida, Koen Koning,
Nikola Djukic, Philipp Stanner, Elle Rhumsaa, Jonathan Corbet,
Alex Deucher, Christian König, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellström,
Helge Deller, John Hubbard, Alistair Popple, Timur Tabi,
Edwin Peer, Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh,
alexeyi, Eliot Courtney, dri-devel, rust-for-linux, linux-doc,
amd-gfx, intel-gfx, intel-xe, linux-fbdev
On Wed, Mar 18, 2026 at 11:59 AM Alice Ryhl <aliceryhl@google.com> wrote:
>
> I'm not sure we have discussed it in detail yet. Both are used in-tree.
Yeah, we have discussed this several times in the list and in meetings
-- please see by other reply.
The handful existing ones I think were all created by Lina (so perhaps
some were kept as-is to avoid extra modifications of the patch -- not
sure) or by you (so those don't count ;)
Cheers,
Miguel
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v13 1/1] rust: interop: Add list module for C linked list interface
2026-03-18 10:53 ` Alexandre Courbot
2026-03-18 10:59 ` Alice Ryhl
@ 2026-03-18 14:21 ` Miguel Ojeda
2026-03-18 14:31 ` Alice Ryhl
1 sibling, 1 reply; 32+ messages in thread
From: Miguel Ojeda @ 2026-03-18 14:21 UTC (permalink / raw)
To: Alexandre Courbot
Cc: Alice Ryhl, Joel Fernandes, linux-kernel, Miguel Ojeda,
Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Andreas Hindborg, Trevor Gross, Alex Gaynor, Danilo Krummrich,
Dave Airlie, David Airlie, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Simona Vetter, Daniel Almeida, Koen Koning,
Nikola Djukic, Philipp Stanner, Elle Rhumsaa, Jonathan Corbet,
Alex Deucher, Christian König, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellström,
Helge Deller, John Hubbard, Alistair Popple, Timur Tabi,
Edwin Peer, Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh,
alexeyi, Eliot Courtney, dri-devel, rust-for-linux, linux-doc,
amd-gfx, intel-gfx, intel-xe, linux-fbdev
On Wed, Mar 18, 2026 at 11:54 AM Alexandre Courbot <acourbot@nvidia.com> wrote:
>
> Ah, so there is a rationale for using a `mod.rs` file after all. What
> are the project-wide guidelines re: `foo.rs` vs `foo/mod.rs`?
Quoting myself from a few years ago:
I don't have a strong opinion either way -- this was originally done
to improve fuzzy searching, see commit 829c2df153d7 ("rust: move `net`
and `sync` modules to uniquely-named files") upstream:
This is so that each file in the module has a unique name instead of the
generic `mod.rs` name. It makes it easier to open files when using fuzzy
finders like `fzf` once names are unique.
Another reason was that it is what upstream Rust recommends:
"Prior to rustc 1.30, using `mod.rs` files was the way to load a
module with nested children. It is encouraged to use the new naming
convention as it is more consistent, and avoids having many files
named mod.rs within a project."
https://doc.rust-lang.org/reference/items/modules.html#r-items.mod.outlined.search-mod
https://doc.rust-lang.org/edition-guide/rust-2018/path-changes.html#no-more-modrs
Now, several other people have argued for the other way over the years.
For instance, one reason is that tab completion can be smoother with
`mod.rs`, e.g. every time you complete something like
`rust/kernel/sync`, you have to decide whether you want `sync.rs` or
`sync/`, and then if you wanted the folder, you have to tab-complete
again.
So I guess it depends if you use more the shell TAB (like Linus really
values on the C folders) or the fuzzy finder (like Wedson argued for
in the commit referenced above).
I personally don't want to bias it one way or the other [*], but
please let's avoid having both mixed if possible (unless there is a
reason not to). I can put the result in the new guidelines rules list
file.
I hope that gives some context!
[*] I would have preferred a middle ground like modules being inside
but repeating the folder name, e.g. `.../pci/pci.rs`, but I doubt that
will ever be supported upstream since one probably wants to support
the other ways at the same time.
Cheers,
Miguel
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH v13 1/1] rust: interop: Add list module for C linked list interface
2026-03-18 14:21 ` Miguel Ojeda
@ 2026-03-18 14:31 ` Alice Ryhl
2026-03-18 14:41 ` Miguel Ojeda
2026-03-18 14:43 ` Danilo Krummrich
0 siblings, 2 replies; 32+ messages in thread
From: Alice Ryhl @ 2026-03-18 14:31 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Alexandre Courbot, Joel Fernandes, linux-kernel, Miguel Ojeda,
Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Andreas Hindborg, Trevor Gross, Alex Gaynor, Danilo Krummrich,
Dave Airlie, David Airlie, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Simona Vetter, Daniel Almeida, Koen Koning,
Nikola Djukic, Philipp Stanner, Elle Rhumsaa, Jonathan Corbet,
Alex Deucher, Christian König, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellström,
Helge Deller, John Hubbard, Alistair Popple, Timur Tabi,
Edwin Peer, Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh,
alexeyi, Eliot Courtney, dri-devel, rust-for-linux, linux-doc,
amd-gfx, intel-gfx, intel-xe, linux-fbdev
On Wed, Mar 18, 2026 at 3:21 PM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
> [*] I would have preferred a middle ground like modules being inside
> but repeating the folder name, e.g. `.../pci/pci.rs`, but I doubt that
> will ever be supported upstream since one probably wants to support
> the other ways at the same time.
In principle this is possible using
#[path = "pci/pci.rs"]
pub mod pci;
Alice
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v13 1/1] rust: interop: Add list module for C linked list interface
2026-03-18 14:31 ` Alice Ryhl
@ 2026-03-18 14:41 ` Miguel Ojeda
2026-03-18 14:49 ` Danilo Krummrich
2026-03-18 14:43 ` Danilo Krummrich
1 sibling, 1 reply; 32+ messages in thread
From: Miguel Ojeda @ 2026-03-18 14:41 UTC (permalink / raw)
To: Alice Ryhl
Cc: Alexandre Courbot, Joel Fernandes, linux-kernel, Miguel Ojeda,
Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Andreas Hindborg, Trevor Gross, Alex Gaynor, Danilo Krummrich,
Dave Airlie, David Airlie, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Simona Vetter, Daniel Almeida, Koen Koning,
Nikola Djukic, Philipp Stanner, Elle Rhumsaa, Jonathan Corbet,
Alex Deucher, Christian König, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellström,
Helge Deller, John Hubbard, Alistair Popple, Timur Tabi,
Edwin Peer, Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh,
alexeyi, Eliot Courtney, dri-devel, rust-for-linux, linux-doc,
amd-gfx, intel-gfx, intel-xe, linux-fbdev
On Wed, Mar 18, 2026 at 3:31 PM Alice Ryhl <aliceryhl@google.com> wrote:
>
> In principle this is possible using
>
> #[path = "pci/pci.rs"]
> pub mod pci;
No, I meant supported natively, i.e. without having to write an extra
file everywhere (which could perhaps be simpler as just a symlink
instead).
We could also generate the `mod.rs` on the fly, but that means a clean
tree isn't great for tooling etc.
Cheers,
Miguel
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v13 1/1] rust: interop: Add list module for C linked list interface
2026-03-18 14:41 ` Miguel Ojeda
@ 2026-03-18 14:49 ` Danilo Krummrich
2026-03-18 18:57 ` Miguel Ojeda
0 siblings, 1 reply; 32+ messages in thread
From: Danilo Krummrich @ 2026-03-18 14:49 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Alice Ryhl, Alexandre Courbot, Joel Fernandes, linux-kernel,
Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Alex Gaynor,
Dave Airlie, David Airlie, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Simona Vetter, Daniel Almeida, Koen Koning,
Nikola Djukic, Philipp Stanner, Elle Rhumsaa, Jonathan Corbet,
Alex Deucher, Christian König, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellström,
Helge Deller, John Hubbard, Alistair Popple, Timur Tabi,
Edwin Peer, Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh,
alexeyi, Eliot Courtney, dri-devel, rust-for-linux, linux-doc,
amd-gfx, intel-gfx, intel-xe, linux-fbdev
On Wed Mar 18, 2026 at 3:41 PM CET, Miguel Ojeda wrote:
> On Wed, Mar 18, 2026 at 3:31 PM Alice Ryhl <aliceryhl@google.com> wrote:
>>
>> In principle this is possible using
>>
>> #[path = "pci/pci.rs"]
>> pub mod pci;
>
> No, I meant supported natively, i.e. without having to write an extra
> file everywhere (which could perhaps be simpler as just a symlink
> instead).
What do you mean with extra file?
renamed: rust/kernel/pci.rs -> rust/kernel/pci/pci.rs
diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
index 34b924819288..4b6396aec030 100644
--- a/rust/kernel/lib.rs
+++ b/rust/kernel/lib.rs
@@ -131,6 +131,7 @@
pub mod opp;
pub mod page;
#[cfg(CONFIG_PCI)]
+#[path = "pci/pci.rs"]
pub mod pci;
pub mod pid_namespace;
pub mod platform;
^ permalink raw reply related [flat|nested] 32+ messages in thread
* Re: [PATCH v13 1/1] rust: interop: Add list module for C linked list interface
2026-03-18 14:49 ` Danilo Krummrich
@ 2026-03-18 18:57 ` Miguel Ojeda
0 siblings, 0 replies; 32+ messages in thread
From: Miguel Ojeda @ 2026-03-18 18:57 UTC (permalink / raw)
To: Danilo Krummrich
Cc: Alice Ryhl, Alexandre Courbot, Joel Fernandes, linux-kernel,
Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Alex Gaynor,
Dave Airlie, David Airlie, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Simona Vetter, Daniel Almeida, Koen Koning,
Nikola Djukic, Philipp Stanner, Elle Rhumsaa, Jonathan Corbet,
Alex Deucher, Christian König, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellström,
Helge Deller, John Hubbard, Alistair Popple, Timur Tabi,
Edwin Peer, Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh,
alexeyi, Eliot Courtney, dri-devel, rust-for-linux, linux-doc,
amd-gfx, intel-gfx, intel-xe, linux-fbdev
On Wed, Mar 18, 2026 at 3:49 PM Danilo Krummrich <dakr@kernel.org> wrote:
>
> What do you mean with extra file?
Right, sorry -- I was probably overfocused on the `mod.rs` symlink for
some reason. We may have talked about generating them on the fly in
the past too, I don't recall anymore.
Let's assume "s/an extra file/extra lines" on my message... If folks
are OK writing manually them, or that we generate them on the fly,
then I am happy I can get the option I always liked! :P
We can chat about it in one of the calls.
Cheers,
Miguel
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v13 1/1] rust: interop: Add list module for C linked list interface
2026-03-18 14:31 ` Alice Ryhl
2026-03-18 14:41 ` Miguel Ojeda
@ 2026-03-18 14:43 ` Danilo Krummrich
1 sibling, 0 replies; 32+ messages in thread
From: Danilo Krummrich @ 2026-03-18 14:43 UTC (permalink / raw)
To: Alice Ryhl
Cc: Miguel Ojeda, Alexandre Courbot, Joel Fernandes, linux-kernel,
Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Alex Gaynor,
Dave Airlie, David Airlie, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Simona Vetter, Daniel Almeida, Koen Koning,
Nikola Djukic, Philipp Stanner, Elle Rhumsaa, Jonathan Corbet,
Alex Deucher, Christian König, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellström,
Helge Deller, John Hubbard, Alistair Popple, Timur Tabi,
Edwin Peer, Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh,
alexeyi, Eliot Courtney, dri-devel, rust-for-linux, linux-doc,
amd-gfx, intel-gfx, intel-xe, linux-fbdev
On Wed Mar 18, 2026 at 3:31 PM CET, Alice Ryhl wrote:
> On Wed, Mar 18, 2026 at 3:21 PM Miguel Ojeda
> <miguel.ojeda.sandonis@gmail.com> wrote:
>> [*] I would have preferred a middle ground like modules being inside
>> but repeating the folder name, e.g. `.../pci/pci.rs`, but I doubt that
>> will ever be supported upstream since one probably wants to support
>> the other ways at the same time.
I very much like this, because, as you said, the pci/ vs. pci.rs completion
issue is indeed annoying me a bit. :)
> In principle this is possible using
>
> #[path = "pci/pci.rs"]
> pub mod pci;
Not exactly pretty, but if it works I think it's worth.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v13 1/1] rust: interop: Add list module for C linked list interface
2026-03-18 8:59 ` Alice Ryhl
2026-03-18 10:53 ` Alexandre Courbot
@ 2026-03-18 13:31 ` Gary Guo
2026-03-18 17:58 ` Joel Fernandes
1 sibling, 1 reply; 32+ messages in thread
From: Gary Guo @ 2026-03-18 13:31 UTC (permalink / raw)
To: Alice Ryhl, Joel Fernandes
Cc: linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, Alex Gaynor, Danilo Krummrich, Dave Airlie,
David Airlie, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Simona Vetter, Daniel Almeida, Koen Koning, Nikola Djukic,
Alexandre Courbot, Philipp Stanner, Elle Rhumsaa, Jonathan Corbet,
Alex Deucher, Christian König, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellström,
Helge Deller, John Hubbard, Alistair Popple, Timur Tabi,
Edwin Peer, Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh,
alexeyi, Eliot Courtney, dri-devel, rust-for-linux, linux-doc,
amd-gfx, intel-gfx, intel-xe, linux-fbdev
On Wed Mar 18, 2026 at 8:59 AM GMT, Alice Ryhl wrote:
> On Tue, Mar 17, 2026 at 04:18:46PM -0400, Joel Fernandes wrote:
>>
>>
>> On 3/17/2026 4:17 PM, Joel Fernandes wrote:
>> > Add a new module `kernel::interop::list` 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>
>> > Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
>> > Acked-by: Alexandre Courbot <acourbot@nvidia.com>
>> > Acked-by: Gary Guo <gary@garyguo.net>
>> > Acked-by: Miguel Ojeda <ojeda@kernel.org>
>> > Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
>> > ---
>> > MAINTAINERS | 8 +
>> > rust/helpers/helpers.c | 1 +
>> > rust/helpers/list.c | 17 ++
>> > rust/kernel/interop.rs | 9 +
>> > rust/kernel/interop/list.rs | 342 ++++++++++++++++++++++++++++++++++++
>> > rust/kernel/lib.rs | 2 +
>> > 6 files changed, 379 insertions(+)
>> > create mode 100644 rust/helpers/list.c
>> > create mode 100644 rust/kernel/interop.rs
>> > create mode 100644 rust/kernel/interop/list.rs
>> >
>> > diff --git a/MAINTAINERS b/MAINTAINERS
>> > index 4bd6b538a51f..e847099efcc2 100644
>> > --- a/MAINTAINERS
>> > +++ b/MAINTAINERS
>> > @@ -23251,6 +23251,14 @@ T: git https://github.com/Rust-for-Linux/linux.git alloc-next
>> > F: rust/kernel/alloc.rs
>> > F: rust/kernel/alloc/
>> >
>> > +RUST [INTEROP]
>> > +M: Joel Fernandes <joelagnelf@nvidia.com>
>> > +M: Alexandre Courbot <acourbot@nvidia.com>
>> > +L: rust-for-linux@vger.kernel.org
>> > +S: Maintained
>> > +T: git https://github.com/Rust-for-Linux/linux.git interop-next
>> > +F: rust/kernel/interop/
>>
>> Sorry, I forgot to add an additional F: for the rust/kernel/interop.rs file.
>> Danilo/Miguel, do you mind adding this when applying?
>
> I think you should consider a mod.rs file to avoid this. It's tiny, and
> just re-exports submodules, so I don't think the "mod.rs name in file
> view" concern is that big, and IMO having files related to interop/
> inside the directory is much better than having them outside.
>
> Alice
I wanted this for all modules in general. For modules that grow into multiple
files we should really use mod.rs and avoid both module_name.rs and the
module_name directory.
Best,
Gary
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v13 1/1] rust: interop: Add list module for C linked list interface
2026-03-18 13:31 ` Gary Guo
@ 2026-03-18 17:58 ` Joel Fernandes
0 siblings, 0 replies; 32+ messages in thread
From: Joel Fernandes @ 2026-03-18 17:58 UTC (permalink / raw)
To: Gary Guo, Alice Ryhl
Cc: linux-kernel, Miguel Ojeda, Boqun Feng, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Alex Gaynor,
Danilo Krummrich, Dave Airlie, David Airlie, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Simona Vetter, Daniel Almeida,
Koen Koning, Nikola Djukic, Alexandre Courbot, Philipp Stanner,
Elle Rhumsaa, Jonathan Corbet, Alex Deucher, Christian König,
Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
Huang Rui, Matthew Auld, Matthew Brost, Lucas De Marchi,
Thomas Hellström, Helge Deller, John Hubbard,
Alistair Popple, Timur Tabi, Edwin Peer, Andrea Righi,
Andy Ritger, Zhi Wang, Balbir Singh, alexeyi, Eliot Courtney,
dri-devel, rust-for-linux, linux-doc, amd-gfx, intel-gfx,
intel-xe, linux-fbdev
On 3/18/2026 9:31 AM, Gary Guo wrote:
> On Wed Mar 18, 2026 at 8:59 AM GMT, Alice Ryhl wrote:
>> On Tue, Mar 17, 2026 at 04:18:46PM -0400, Joel Fernandes wrote:
>>>
>>>
>>> On 3/17/2026 4:17 PM, Joel Fernandes wrote:
>>>> Add a new module `kernel::interop::list` 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>
>>>> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
>>>> Acked-by: Alexandre Courbot <acourbot@nvidia.com>
>>>> Acked-by: Gary Guo <gary@garyguo.net>
>>>> Acked-by: Miguel Ojeda <ojeda@kernel.org>
>>>> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
>>>> ---
>>>> MAINTAINERS | 8 +
>>>> rust/helpers/helpers.c | 1 +
>>>> rust/helpers/list.c | 17 ++
>>>> rust/kernel/interop.rs | 9 +
>>>> rust/kernel/interop/list.rs | 342 ++++++++++++++++++++++++++++++++++++
>>>> rust/kernel/lib.rs | 2 +
>>>> 6 files changed, 379 insertions(+)
>>>> create mode 100644 rust/helpers/list.c
>>>> create mode 100644 rust/kernel/interop.rs
>>>> create mode 100644 rust/kernel/interop/list.rs
>>>>
>>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>>> index 4bd6b538a51f..e847099efcc2 100644
>>>> --- a/MAINTAINERS
>>>> +++ b/MAINTAINERS
>>>> @@ -23251,6 +23251,14 @@ T: git https://github.com/Rust-for-Linux/linux.git alloc-next
>>>> F: rust/kernel/alloc.rs
>>>> F: rust/kernel/alloc/
>>>>
>>>> +RUST [INTEROP]
>>>> +M: Joel Fernandes <joelagnelf@nvidia.com>
>>>> +M: Alexandre Courbot <acourbot@nvidia.com>
>>>> +L: rust-for-linux@vger.kernel.org
>>>> +S: Maintained
>>>> +T: git https://github.com/Rust-for-Linux/linux.git interop-next
>>>> +F: rust/kernel/interop/
>>>
>>> Sorry, I forgot to add an additional F: for the rust/kernel/interop.rs file.
>>> Danilo/Miguel, do you mind adding this when applying?
>>
>> I think you should consider a mod.rs file to avoid this. It's tiny, and
>> just re-exports submodules, so I don't think the "mod.rs name in file
>> view" concern is that big, and IMO having files related to interop/
>> inside the directory is much better than having them outside.
>>
>> Alice
>
> I wanted this for all modules in general. For modules that grow into multiple
> files we should really use mod.rs and avoid both module_name.rs and the
> module_name directory.
>
This is how it was, and I changed it based on Alex's feedback:
https://lore.kernel.org/all/DH3XD8NUDJNG.2IMPYC40D8DXI@nvidia.com/
I am Ok with both approaches. I would request Danilo if he's applying it,
that if he could do so without my additional re-send.
thanks,
--
Joel Fernandes
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v13 1/1] rust: interop: Add list module for C linked list interface
2026-03-17 20:17 ` [PATCH v13 1/1] " Joel Fernandes
2026-03-17 20:18 ` Joel Fernandes
@ 2026-03-18 9:10 ` Alice Ryhl
2026-03-18 18:55 ` Joel Fernandes
2026-03-18 12:40 ` Alice Ryhl
2026-03-19 11:39 ` Gary Guo
3 siblings, 1 reply; 32+ messages in thread
From: Alice Ryhl @ 2026-03-18 9:10 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, Alex Gaynor, Danilo Krummrich, Dave Airlie,
David Airlie, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Simona Vetter, Daniel Almeida, Koen Koning, Nikola Djukic,
Alexandre Courbot, Philipp Stanner, Elle Rhumsaa, Jonathan Corbet,
Alex Deucher, Christian König, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellström,
Helge Deller, John Hubbard, Alistair Popple, Timur Tabi,
Edwin Peer, Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh,
alexeyi, Eliot Courtney, dri-devel, rust-for-linux, linux-doc,
amd-gfx, intel-gfx, intel-xe, linux-fbdev
On Tue, Mar 17, 2026 at 04:17:10PM -0400, Joel Fernandes wrote:
> Add a new module `kernel::interop::list` 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>
> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
> Acked-by: Alexandre Courbot <acourbot@nvidia.com>
> Acked-by: Gary Guo <gary@garyguo.net>
> Acked-by: Miguel Ojeda <ojeda@kernel.org>
> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
I have a few nits below. But overall I think this looks ok:
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Please do consider my mod.rs suggestion too, though.
> +//! ```
> +//! use kernel::{
> +//! bindings,
> +//! clist_create,
IMO the automatic re-exports of macros at the root shouldn't be used.
Import it from kernel::interop::list::clist_create instead.
Note that you need to put a re-export below macro definition to do this.
macro_rules! clist_create {
(unsafe { $head:ident, $rust_type:ty, $c_type:ty, $($field:tt).+ }) => {{
// Compile-time check that field path is a `list_head`.
// SAFETY: `p` is a valid pointer to `$c_type`.
let _: fn(*const $c_type) -> *const $crate::bindings::list_head =
|p| unsafe { &raw const (*p).$($field).+ };
// Calculate offset and create `CList`.
const OFFSET: usize = ::core::mem::offset_of!($c_type, $($field).+);
// SAFETY: The caller of this macro is responsible for ensuring safety.
unsafe { $crate::interop::list::CList::<$rust_type, OFFSET>::from_raw($head) }
}};
}
pub use clist_create; // <-- you need this
See tracepoint.rs or any of the other macros for an example.
> +//! // Create typed [`CList`] from sentinel head.
> +//! // SAFETY: `head` is valid and initialized, items are `SampleItemC` with
> +//! // embedded `link` field, and `Item` is `#[repr(transparent)]` over `SampleItemC`.
> +//! let list = clist_create!(unsafe { head, Item, SampleItemC, link });
Did you try using this in your real use-case? You require `head` to be
an :ident, but I think for any 'struct list_head' not stored on the
stack, accepting an :expr would be easier to use so that you can just
pass `&raw mut my_c_struct.the_list_head` directly to the macro. Right
now you have to put the raw pointer in a local variable first.
Alice
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH v13 1/1] rust: interop: Add list module for C linked list interface
2026-03-18 9:10 ` Alice Ryhl
@ 2026-03-18 18:55 ` Joel Fernandes
0 siblings, 0 replies; 32+ messages in thread
From: Joel Fernandes @ 2026-03-18 18:55 UTC (permalink / raw)
To: Alice Ryhl
Cc: linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, Alex Gaynor, Danilo Krummrich, Dave Airlie,
David Airlie, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Simona Vetter, Daniel Almeida, Koen Koning, Nikola Djukic,
Alexandre Courbot, Philipp Stanner, Elle Rhumsaa, Jonathan Corbet,
Alex Deucher, Christian König, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellström,
Helge Deller, John Hubbard, Alistair Popple, Timur Tabi,
Edwin Peer, Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh,
alexeyi, Eliot Courtney, dri-devel, rust-for-linux, linux-doc,
amd-gfx, intel-gfx, intel-xe, linux-fbdev
On 3/18/2026 5:10 AM, Alice Ryhl wrote:
> On Tue, Mar 17, 2026 at 04:17:10PM -0400, Joel Fernandes wrote:
>> Add a new module `kernel::interop::list` 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>
>> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
>> Acked-by: Alexandre Courbot <acourbot@nvidia.com>
>> Acked-by: Gary Guo <gary@garyguo.net>
>> Acked-by: Miguel Ojeda <ojeda@kernel.org>
>> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
>
> I have a few nits below. But overall I think this looks ok:
>
> Reviewed-by: Alice Ryhl <aliceryhl@google.com>
>
> Please do consider my mod.rs suggestion too, though.
sure.
>
>> +//! ```
>> +//! use kernel::{
>> +//! bindings,
>> +//! clist_create,
>
> IMO the automatic re-exports of macros at the root shouldn't be used.
> Import it from kernel::interop::list::clist_create instead.
>
> Note that you need to put a re-export below macro definition to do this.
>
> macro_rules! clist_create {
> (unsafe { $head:ident, $rust_type:ty, $c_type:ty, $($field:tt).+ }) => {{
> // Compile-time check that field path is a `list_head`.
> // SAFETY: `p` is a valid pointer to `$c_type`.
> let _: fn(*const $c_type) -> *const $crate::bindings::list_head =
> |p| unsafe { &raw const (*p).$($field).+ };
>
> // Calculate offset and create `CList`.
> const OFFSET: usize = ::core::mem::offset_of!($c_type, $($field).+);
> // SAFETY: The caller of this macro is responsible for ensuring safety.
> unsafe { $crate::interop::list::CList::<$rust_type, OFFSET>::from_raw($head) }
> }};
> }
> pub use clist_create; // <-- you need this
>
> See tracepoint.rs or any of the other macros for an example.
Ok.
>
>> +//! // Create typed [`CList`] from sentinel head.
>> +//! // SAFETY: `head` is valid and initialized, items are `SampleItemC` with
>> +//! // embedded `link` field, and `Item` is `#[repr(transparent)]` over `SampleItemC`.
>> +//! let list = clist_create!(unsafe { head, Item, SampleItemC, link });
>
> Did you try using this in your real use-case? You require `head` to be
> an :ident, but I think for any 'struct list_head' not stored on the
> stack, accepting an :expr would be easier to use so that you can just
> pass `&raw mut my_c_struct.the_list_head` directly to the macro. Right
> now you have to put the raw pointer in a local variable first.
For buddy.rs usecase, currently we do put it in a local variable so it
works fine. Not doing :ident was causing clippy errors.
warning: this macro expands metavariables in an unsafe block
--> rust/kernel/interop/list.rs:341:9
|
341 | unsafe { $crate::interop::list::CList::<$rust_type,
OFFSET>::from_raw($head) }
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: this allows the user of the macro to write unsafe code outside
of an unsafe block
= help: consider expanding any metavariables outside of this block,
e.g. by storing them in a variable
= help: ... or also expand referenced metavariables in a safe context
to require an unsafe block at callsite
= help: for further information visit
https://rust-lang.github.io/rust-clippy/master/index.html#macro_metavars_in_unsafe
= note: `-W clippy::macro-metavars-in-unsafe` implied by `-W clippy::all`
= help: to override `-W clippy::all` add
`#[allow(clippy::macro_metavars_in_unsafe)]`
thanks,
--
Joel Fernandes
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v13 1/1] rust: interop: Add list module for C linked list interface
2026-03-17 20:17 ` [PATCH v13 1/1] " Joel Fernandes
2026-03-17 20:18 ` Joel Fernandes
2026-03-18 9:10 ` Alice Ryhl
@ 2026-03-18 12:40 ` Alice Ryhl
2026-03-18 14:03 ` Miguel Ojeda
2026-03-18 18:31 ` Joel Fernandes
2026-03-19 11:39 ` Gary Guo
3 siblings, 2 replies; 32+ messages in thread
From: Alice Ryhl @ 2026-03-18 12:40 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, Alex Gaynor, Danilo Krummrich, Dave Airlie,
David Airlie, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Simona Vetter, Daniel Almeida, Koen Koning, Nikola Djukic,
Alexandre Courbot, Philipp Stanner, Elle Rhumsaa, Jonathan Corbet,
Alex Deucher, Christian König, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellström,
Helge Deller, John Hubbard, Alistair Popple, Timur Tabi,
Edwin Peer, Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh,
alexeyi, Eliot Courtney, dri-devel, rust-for-linux, linux-doc,
amd-gfx, intel-gfx, intel-xe, linux-fbdev
On Tue, Mar 17, 2026 at 04:17:10PM -0400, Joel Fernandes wrote:
> Add a new module `kernel::interop::list` 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>
> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
> Acked-by: Alexandre Courbot <acourbot@nvidia.com>
> Acked-by: Gary Guo <gary@garyguo.net>
> Acked-by: Miguel Ojeda <ojeda@kernel.org>
> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
> ---
> MAINTAINERS | 8 +
> rust/helpers/helpers.c | 1 +
> rust/helpers/list.c | 17 ++
> rust/kernel/interop.rs | 9 +
> rust/kernel/interop/list.rs | 342 ++++++++++++++++++++++++++++++++++++
> rust/kernel/lib.rs | 2 +
> 6 files changed, 379 insertions(+)
> create mode 100644 rust/helpers/list.c
> create mode 100644 rust/kernel/interop.rs
> create mode 100644 rust/kernel/interop/list.rs
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4bd6b538a51f..e847099efcc2 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -23251,6 +23251,14 @@ T: git https://github.com/Rust-for-Linux/linux.git alloc-next
> F: rust/kernel/alloc.rs
> F: rust/kernel/alloc/
>
> +RUST [INTEROP]
> +M: Joel Fernandes <joelagnelf@nvidia.com>
> +M: Alexandre Courbot <acourbot@nvidia.com>
> +L: rust-for-linux@vger.kernel.org
> +S: Maintained
> +T: git https://github.com/Rust-for-Linux/linux.git interop-next
> +F: rust/kernel/interop/
> +
> RUST [NUM]
> M: Alexandre Courbot <acourbot@nvidia.com>
> R: Yury Norov <yury.norov@gmail.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..18095a5593c5
> --- /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/interop.rs b/rust/kernel/interop.rs
> new file mode 100644
> index 000000000000..b88140cf76dc
> --- /dev/null
> +++ b/rust/kernel/interop.rs
> @@ -0,0 +1,9 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +//! Infrastructure for interfacing Rust code with C kernel subsystems.
> +//!
> +//! This module is intended for low-level, unsafe Rust infrastructure code
> +//! that interoperates between Rust and C. It is NOT for use directly in
> +//! Rust drivers.
> +
> +pub mod list;
> diff --git a/rust/kernel/interop/list.rs b/rust/kernel/interop/list.rs
> new file mode 100644
> index 000000000000..328f6b0de2ce
> --- /dev/null
> +++ b/rust/kernel/interop/list.rs
> @@ -0,0 +1,342 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +//! Rust interface for C doubly circular intrusive linked lists.
> +//!
> +//! This module provides Rust abstractions for iterating over C `list_head`-based
> +//! linked lists. It should only be used for cases where C and Rust code share
> +//! direct access to the same linked list through a C interop interface.
> +//!
> +//! Note: This *must not* be used by Rust components that just need a linked list
> +//! primitive. Use [`kernel::list::List`] instead.
> +//!
> +//! # 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: `ptr` points to a valid `MaybeUninit<SampleItemC>`.
> +//! # unsafe { (*ptr).value = i as i32 * 10 };
> +//! # // SAFETY: `&raw mut` creates a pointer valid for `INIT_LIST_HEAD`.
> +//! # unsafe { bindings::INIT_LIST_HEAD(&raw mut (*ptr).link) };
> +//! # // SAFETY: `link` was just initialized and `head` is a valid list head.
> +//! # unsafe { 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:
> +//! ///
> +//! /// ```c
> +//! /// 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 and initialized, items are `SampleItemC` with
> +//! // embedded `link` field, and `Item` is `#[repr(transparent)]` over `SampleItemC`.
> +//! let list = clist_create!(unsafe { head, Item, SampleItemC, link });
Bad news.
My build triggers this warning:
error: statement has unnecessary safety comment
--> rust/doctests_kernel_generated.rs:7103:1
|
7103 | let list = clist_create!(unsafe { head, Item, SampleItemC, link });
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
help: consider removing the safety comment
--> rust/doctests_kernel_generated.rs:7101:4
|
7101 | // SAFETY: `head` is valid and initialized, items are `SampleItemC` with
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
= help: for further information visit https://rust-lang.github.io/rust-clippy/rust-1.94.0/index.html#unnecessary_safety_comment
= note: `-D clippy::unnecessary-safety-comment` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(clippy::unnecessary_safety_comment)]`
This probably needs to be:
unsafe { clist_create!(head, Item, SampleItemC, link) }
Alice
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH v13 1/1] rust: interop: Add list module for C linked list interface
2026-03-18 12:40 ` Alice Ryhl
@ 2026-03-18 14:03 ` Miguel Ojeda
2026-03-18 18:31 ` Joel Fernandes
1 sibling, 0 replies; 32+ messages in thread
From: Miguel Ojeda @ 2026-03-18 14:03 UTC (permalink / raw)
To: Alice Ryhl
Cc: Joel Fernandes, linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, Alex Gaynor, Danilo Krummrich, Dave Airlie,
David Airlie, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Simona Vetter, Daniel Almeida, Koen Koning, Nikola Djukic,
Alexandre Courbot, Philipp Stanner, Elle Rhumsaa, Jonathan Corbet,
Alex Deucher, Christian König, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellström,
Helge Deller, John Hubbard, Alistair Popple, Timur Tabi,
Edwin Peer, Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh,
alexeyi, Eliot Courtney, dri-devel, rust-for-linux, linux-doc,
amd-gfx, intel-gfx, intel-xe, linux-fbdev
On Wed, Mar 18, 2026 at 1:40 PM Alice Ryhl <aliceryhl@google.com> wrote:
>
> My build triggers this warning:
I reported that in the previous version -- Joel, you said you used the
workaround I mentioned, but I don't see it here.
Did you decide otherwise and retested and you couldn't reproduce it?
It is fine either way -- I am asking because if we decide to keep and
use that "fake `unsafe` block" pattern, then I should create the issue
to ask Clippy to support it.
Thanks!
Cheers,
Miguel
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v13 1/1] rust: interop: Add list module for C linked list interface
2026-03-18 12:40 ` Alice Ryhl
2026-03-18 14:03 ` Miguel Ojeda
@ 2026-03-18 18:31 ` Joel Fernandes
2026-03-18 18:43 ` Joel Fernandes
2026-03-18 18:57 ` Miguel Ojeda
1 sibling, 2 replies; 32+ messages in thread
From: Joel Fernandes @ 2026-03-18 18:31 UTC (permalink / raw)
To: Alice Ryhl
Cc: linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, Alex Gaynor, Danilo Krummrich, Dave Airlie,
David Airlie, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Simona Vetter, Daniel Almeida, Koen Koning, Nikola Djukic,
Alexandre Courbot, Philipp Stanner, Elle Rhumsaa, Jonathan Corbet,
Alex Deucher, Christian König, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellström,
Helge Deller, John Hubbard, Alistair Popple, Timur Tabi,
Edwin Peer, Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh,
alexeyi, Eliot Courtney, dri-devel, rust-for-linux, linux-doc,
amd-gfx, intel-gfx, intel-xe, linux-fbdev
On 3/18/2026 8:40 AM, Alice Ryhl wrote:
> On Tue, Mar 17, 2026 at 04:17:10PM -0400, Joel Fernandes wrote:
>> Add a new module `kernel::interop::list` 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>
>> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
>> Acked-by: Alexandre Courbot <acourbot@nvidia.com>
>> Acked-by: Gary Guo <gary@garyguo.net>
>> Acked-by: Miguel Ojeda <ojeda@kernel.org>
>> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
>> ---
>> MAINTAINERS | 8 +
>> rust/helpers/helpers.c | 1 +
>> rust/helpers/list.c | 17 ++
>> rust/kernel/interop.rs | 9 +
>> rust/kernel/interop/list.rs | 342 ++++++++++++++++++++++++++++++++++++
>> rust/kernel/lib.rs | 2 +
>> 6 files changed, 379 insertions(+)
>> create mode 100644 rust/helpers/list.c
>> create mode 100644 rust/kernel/interop.rs
>> create mode 100644 rust/kernel/interop/list.rs
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 4bd6b538a51f..e847099efcc2 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -23251,6 +23251,14 @@ T: git https://github.com/Rust-for-Linux/linux.git alloc-next
>> F: rust/kernel/alloc.rs
>> F: rust/kernel/alloc/
>>
>> +RUST [INTEROP]
>> +M: Joel Fernandes <joelagnelf@nvidia.com>
>> +M: Alexandre Courbot <acourbot@nvidia.com>
>> +L: rust-for-linux@vger.kernel.org
>> +S: Maintained
>> +T: git https://github.com/Rust-for-Linux/linux.git interop-next
>> +F: rust/kernel/interop/
>> +
>> RUST [NUM]
>> M: Alexandre Courbot <acourbot@nvidia.com>
>> R: Yury Norov <yury.norov@gmail.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..18095a5593c5
>> --- /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/interop.rs b/rust/kernel/interop.rs
>> new file mode 100644
>> index 000000000000..b88140cf76dc
>> --- /dev/null
>> +++ b/rust/kernel/interop.rs
>> @@ -0,0 +1,9 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +
>> +//! Infrastructure for interfacing Rust code with C kernel subsystems.
>> +//!
>> +//! This module is intended for low-level, unsafe Rust infrastructure code
>> +//! that interoperates between Rust and C. It is NOT for use directly in
>> +//! Rust drivers.
>> +
>> +pub mod list;
>> diff --git a/rust/kernel/interop/list.rs b/rust/kernel/interop/list.rs
>> new file mode 100644
>> index 000000000000..328f6b0de2ce
>> --- /dev/null
>> +++ b/rust/kernel/interop/list.rs
>> @@ -0,0 +1,342 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +
>> +//! Rust interface for C doubly circular intrusive linked lists.
>> +//!
>> +//! This module provides Rust abstractions for iterating over C `list_head`-based
>> +//! linked lists. It should only be used for cases where C and Rust code share
>> +//! direct access to the same linked list through a C interop interface.
>> +//!
>> +//! Note: This *must not* be used by Rust components that just need a linked list
>> +//! primitive. Use [`kernel::list::List`] instead.
>> +//!
>> +//! # 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: `ptr` points to a valid `MaybeUninit<SampleItemC>`.
>> +//! # unsafe { (*ptr).value = i as i32 * 10 };
>> +//! # // SAFETY: `&raw mut` creates a pointer valid for `INIT_LIST_HEAD`.
>> +//! # unsafe { bindings::INIT_LIST_HEAD(&raw mut (*ptr).link) };
>> +//! # // SAFETY: `link` was just initialized and `head` is a valid list head.
>> +//! # unsafe { 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:
>> +//! ///
>> +//! /// ```c
>> +//! /// 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 and initialized, items are `SampleItemC` with
>> +//! // embedded `link` field, and `Item` is `#[repr(transparent)]` over `SampleItemC`.
>> +//! let list = clist_create!(unsafe { head, Item, SampleItemC, link });
>
> Bad news.
>
> My build triggers this warning:
>
> error: statement has unnecessary safety comment
> --> rust/doctests_kernel_generated.rs:7103:1
> |
> 7103 | let list = clist_create!(unsafe { head, Item, SampleItemC, link });
> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> |
> help: consider removing the safety comment
> --> rust/doctests_kernel_generated.rs:7101:4
> |
> 7101 | // SAFETY: `head` is valid and initialized, items are `SampleItemC` with
> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> = help: for further information visit https://rust-lang.github.io/rust-clippy/rust-1.94.0/index.html#unnecessary_safety_comment
> = note: `-D clippy::unnecessary-safety-comment` implied by `-D warnings`
> = help: to override `-D warnings` add `#[allow(clippy::unnecessary_safety_comment)]`
>
> This probably needs to be:
>
> unsafe { clist_create!(head, Item, SampleItemC, link) }
Oops, I sometimes run clippy wrong. I did: "CLIPPY=1 make" instead of "make
CLIPPY=1", the reason is habit. I have been doing "LLVM=1 make" for llvm
builds since many years.
Anyway, the fix is simple, just need to do // SAFETY*: as Miguel suggests
here, instead of // SAFETY:
https://lore.kernel.org/all/CANiq72kEnDyUpnWMZmheJytjioeiJUK_C-yQJk77dPid89LExw@mail.gmail.com/
Should be easy to do on apply if Danilo doesn't mind. :) I verified on my
setup that it fixes it.
thanks,
--
Joel Fernandes
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH v13 1/1] rust: interop: Add list module for C linked list interface
2026-03-18 18:31 ` Joel Fernandes
@ 2026-03-18 18:43 ` Joel Fernandes
2026-03-18 18:57 ` Miguel Ojeda
1 sibling, 0 replies; 32+ messages in thread
From: Joel Fernandes @ 2026-03-18 18:43 UTC (permalink / raw)
To: Alice Ryhl
Cc: linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, Alex Gaynor, Danilo Krummrich, Dave Airlie,
David Airlie, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Simona Vetter, Daniel Almeida, Koen Koning, Nikola Djukic,
Alexandre Courbot, Philipp Stanner, Elle Rhumsaa, Jonathan Corbet,
Alex Deucher, Christian König, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellström,
Helge Deller, John Hubbard, Alistair Popple, Timur Tabi,
Edwin Peer, Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh,
alexeyi, Eliot Courtney, dri-devel, rust-for-linux, linux-doc,
amd-gfx, intel-gfx, intel-xe, linux-fbdev
On 3/18/2026 2:31 PM, Joel Fernandes wrote:
>
>
> On 3/18/2026 8:40 AM, Alice Ryhl wrote:
>> On Tue, Mar 17, 2026 at 04:17:10PM -0400, Joel Fernandes wrote:
>>> Add a new module `kernel::interop::list` 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>
>>> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
>>> Acked-by: Alexandre Courbot <acourbot@nvidia.com>
>>> Acked-by: Gary Guo <gary@garyguo.net>
>>> Acked-by: Miguel Ojeda <ojeda@kernel.org>
>>> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
>>> ---
>>> MAINTAINERS | 8 +
>>> rust/helpers/helpers.c | 1 +
>>> rust/helpers/list.c | 17 ++
>>> rust/kernel/interop.rs | 9 +
>>> rust/kernel/interop/list.rs | 342 ++++++++++++++++++++++++++++++++++++
>>> rust/kernel/lib.rs | 2 +
>>> 6 files changed, 379 insertions(+)
>>> create mode 100644 rust/helpers/list.c
>>> create mode 100644 rust/kernel/interop.rs
>>> create mode 100644 rust/kernel/interop/list.rs
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index 4bd6b538a51f..e847099efcc2 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -23251,6 +23251,14 @@ T: git https://github.com/Rust-for-Linux/linux.git alloc-next
>>> F: rust/kernel/alloc.rs
>>> F: rust/kernel/alloc/
>>>
>>> +RUST [INTEROP]
>>> +M: Joel Fernandes <joelagnelf@nvidia.com>
>>> +M: Alexandre Courbot <acourbot@nvidia.com>
>>> +L: rust-for-linux@vger.kernel.org
>>> +S: Maintained
>>> +T: git https://github.com/Rust-for-Linux/linux.git interop-next
>>> +F: rust/kernel/interop/
>>> +
>>> RUST [NUM]
>>> M: Alexandre Courbot <acourbot@nvidia.com>
>>> R: Yury Norov <yury.norov@gmail.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..18095a5593c5
>>> --- /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/interop.rs b/rust/kernel/interop.rs
>>> new file mode 100644
>>> index 000000000000..b88140cf76dc
>>> --- /dev/null
>>> +++ b/rust/kernel/interop.rs
>>> @@ -0,0 +1,9 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +
>>> +//! Infrastructure for interfacing Rust code with C kernel subsystems.
>>> +//!
>>> +//! This module is intended for low-level, unsafe Rust infrastructure code
>>> +//! that interoperates between Rust and C. It is NOT for use directly in
>>> +//! Rust drivers.
>>> +
>>> +pub mod list;
>>> diff --git a/rust/kernel/interop/list.rs b/rust/kernel/interop/list.rs
>>> new file mode 100644
>>> index 000000000000..328f6b0de2ce
>>> --- /dev/null
>>> +++ b/rust/kernel/interop/list.rs
>>> @@ -0,0 +1,342 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +
>>> +//! Rust interface for C doubly circular intrusive linked lists.
>>> +//!
>>> +//! This module provides Rust abstractions for iterating over C `list_head`-based
>>> +//! linked lists. It should only be used for cases where C and Rust code share
>>> +//! direct access to the same linked list through a C interop interface.
>>> +//!
>>> +//! Note: This *must not* be used by Rust components that just need a linked list
>>> +//! primitive. Use [`kernel::list::List`] instead.
>>> +//!
>>> +//! # 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: `ptr` points to a valid `MaybeUninit<SampleItemC>`.
>>> +//! # unsafe { (*ptr).value = i as i32 * 10 };
>>> +//! # // SAFETY: `&raw mut` creates a pointer valid for `INIT_LIST_HEAD`.
>>> +//! # unsafe { bindings::INIT_LIST_HEAD(&raw mut (*ptr).link) };
>>> +//! # // SAFETY: `link` was just initialized and `head` is a valid list head.
>>> +//! # unsafe { 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:
>>> +//! ///
>>> +//! /// ```c
>>> +//! /// 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 and initialized, items are `SampleItemC` with
>>> +//! // embedded `link` field, and `Item` is `#[repr(transparent)]` over `SampleItemC`.
>>> +//! let list = clist_create!(unsafe { head, Item, SampleItemC, link });
>>
>> Bad news.
>>
>> My build triggers this warning:
>>
>> error: statement has unnecessary safety comment
>> --> rust/doctests_kernel_generated.rs:7103:1
>> |
>> 7103 | let list = clist_create!(unsafe { head, Item, SampleItemC, link });
>> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> |
>> help: consider removing the safety comment
>> --> rust/doctests_kernel_generated.rs:7101:4
>> |
>> 7101 | // SAFETY: `head` is valid and initialized, items are `SampleItemC` with
>> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> = help: for further information visit https://rust-lang.github.io/rust-clippy/rust-1.94.0/index.html#unnecessary_safety_comment
>> = note: `-D clippy::unnecessary-safety-comment` implied by `-D warnings`
>> = help: to override `-D warnings` add `#[allow(clippy::unnecessary_safety_comment)]`
>>
>> This probably needs to be:
>>
>> unsafe { clist_create!(head, Item, SampleItemC, link) }
>
> Oops, I sometimes run clippy wrong. I did: "CLIPPY=1 make" instead of "make
> CLIPPY=1", the reason is habit. I have been doing "LLVM=1 make" for llvm
> builds since many years.
>
> Anyway, the fix is simple, just need to do // SAFETY*: as Miguel suggests
> here, instead of // SAFETY:
> https://lore.kernel.org/all/CANiq72kEnDyUpnWMZmheJytjioeiJUK_C-yQJk77dPid89LExw@mail.gmail.com/
>
> Should be easy to do on apply if Danilo doesn't mind. :) I verified on my
> setup that it fixes it.
Here is the clist fixup fixing both the clippy errors in list.rs:
https://git.kernel.org/pub/scm/linux/kernel/git/jfern/linux.git/commit/?h=nova/mm&id=226e1c75932aec3fde66b4b4a36abd8de919c6da
Thanks.
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH v13 1/1] rust: interop: Add list module for C linked list interface
2026-03-18 18:31 ` Joel Fernandes
2026-03-18 18:43 ` Joel Fernandes
@ 2026-03-18 18:57 ` Miguel Ojeda
2026-03-18 19:24 ` Joel Fernandes
2026-03-23 0:07 ` Alejandra González
1 sibling, 2 replies; 32+ messages in thread
From: Miguel Ojeda @ 2026-03-18 18:57 UTC (permalink / raw)
To: Joel Fernandes, Alejandra González
Cc: Alice Ryhl, linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, Alex Gaynor, Danilo Krummrich, Dave Airlie,
David Airlie, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Simona Vetter, Daniel Almeida, Koen Koning, Nikola Djukic,
Alexandre Courbot, Philipp Stanner, Elle Rhumsaa, Jonathan Corbet,
Alex Deucher, Christian König, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellström,
Helge Deller, John Hubbard, Alistair Popple, Timur Tabi,
Edwin Peer, Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh,
alexeyi, Eliot Courtney, dri-devel, rust-for-linux, linux-doc,
amd-gfx, intel-gfx, intel-xe, linux-fbdev
On Wed, Mar 18, 2026 at 7:31 PM Joel Fernandes <joelagnelf@nvidia.com> wrote:
>
> Anyway, the fix is simple, just need to do // SAFETY*: as Miguel suggests
> here, instead of // SAFETY:
> https://lore.kernel.org/all/CANiq72kEnDyUpnWMZmheJytjioeiJUK_C-yQJk77dPid89LExw@mail.gmail.com/
So, to clarify, I suggested it as a temporary thing we could do if we
want to use that "fake `unsafe` block in macro matcher" pattern more
and more.
i.e. if we plan to use the pattern more, then I am happy to ask
upstream if it would make sense for Clippy to recognize it (or perhaps
it is just a false negative instead of a false positive, given
`impl_device_context_deref`), so that we don't need a hacked safety
tag (Cc'ing Alejandra).
But if we could put it outside, then we wouldn't need any of that.
Unsafe macros support could help perhaps here, which I have had it in
our wishlist too (https://github.com/Rust-for-Linux/linux/issues/354),
but I guess the fake block could still be useful to make only certain
macro arms unsafe? (Perhaps Rust could allow `unsafe` just at the
start of each arm for that...).
Cheers,
Miguel
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v13 1/1] rust: interop: Add list module for C linked list interface
2026-03-18 18:57 ` Miguel Ojeda
@ 2026-03-18 19:24 ` Joel Fernandes
2026-03-19 11:59 ` Alexandre Courbot
2026-03-23 0:07 ` Alejandra González
1 sibling, 1 reply; 32+ messages in thread
From: Joel Fernandes @ 2026-03-18 19:24 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Alejandra González, Alice Ryhl, linux-kernel, Miguel Ojeda,
Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Andreas Hindborg, Trevor Gross, Alex Gaynor, Danilo Krummrich,
Dave Airlie, David Airlie, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Simona Vetter, Daniel Almeida, Koen Koning,
Nikola Djukic, Alexandre Courbot, Philipp Stanner, Elle Rhumsaa,
Jonathan Corbet, Alex Deucher, Christian König, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, Huang Rui,
Matthew Auld, Matthew Brost, Lucas De Marchi,
Thomas Hellström, Helge Deller, John Hubbard,
Alistair Popple, Timur Tabi, Edwin Peer, Andrea Righi,
Andy Ritger, Zhi Wang, Balbir Singh, alexeyi, Eliot Courtney,
dri-devel, rust-for-linux, linux-doc, amd-gfx, intel-gfx,
intel-xe, linux-fbdev
On Wed, Mar 18, 2026 at 07:57:14PM +0100, Miguel Ojeda wrote:
> On Wed, Mar 18, 2026 at 7:31 PM Joel Fernandes <joelagnelf@nvidia.com> wrote:
> >
> > Anyway, the fix is simple, just need to do // SAFETY*: as Miguel suggests
> > here, instead of // SAFETY:
> > https://lore.kernel.org/all/CANiq72kEnDyUpnWMZmheJytjioeiJUK_C-yQJk77dPid89LExw@mail.gmail.com/
>
> So, to clarify, I suggested it as a temporary thing we could do if we
> want to use that "fake `unsafe` block in macro matcher" pattern more
> and more.
>
> i.e. if we plan to use the pattern more, then I am happy to ask
> upstream if it would make sense for Clippy to recognize it (or perhaps
> it is just a false negative instead of a false positive, given
> `impl_device_context_deref`), so that we don't need a hacked safety
> tag (Cc'ing Alejandra).
>
> But if we could put it outside, then we wouldn't need any of that.
> Unsafe macros support could help perhaps here, which I have had it in
> our wishlist too (https://github.com/Rust-for-Linux/linux/issues/354),
> but I guess the fake block could still be useful to make only certain
> macro arms unsafe? (Perhaps Rust could allow `unsafe` just at the
> start of each arm for that...).
Even if I reworked the macro to be outisde, it doesn't work as below, still
need the 'disabled' comment on the macro's generate unsafe { } block below.
If we don't want the SAFETY*: hack, we could do the following.
Perhaps, we can file the github bug and also do the below. Once the
github bug is fixed, we could remove the 'disable lint' below.
Thoughts?
---8<-----------------------
diff --git a/rust/kernel/interop/list.rs b/rust/kernel/interop/list.rs
index 495497f0405e..dfa2e1490202 100644
--- a/rust/kernel/interop/list.rs
+++ b/rust/kernel/interop/list.rs
@@ -73,7 +73,7 @@
//!
//!
//! // Create typed [`CList`] from sentinel head.
-//! // SAFETY*: `head` is valid and initialized, items are `SampleItemC` with
+//! // SAFETY: `head` is valid and initialized, items are `SampleItemC` with
//! // embedded `link` field, and `Item` is `#[repr(transparent)]` over `SampleItemC`.
//! let list = clist_create!(unsafe { head, Item, SampleItemC, link });
//!
@@ -328,17 +328,19 @@ impl<'a, T, const OFFSET: usize> FusedIterator for CListIter<'a, T, OFFSET> {}
/// Refer to the examples in the [`crate::interop::list`] module documentation.
#[macro_export]
macro_rules! clist_create {
- (unsafe { $head:ident, $rust_type:ty, $c_type:ty, $($field:tt).+ }) => {{
+ (unsafe { $head:ident, $rust_type:ty, $c_type:ty, $($field:tt).+ }) => (
+ // SAFETY: disable lint.
+ unsafe { {{
// Compile-time check that field path is a `list_head`.
let _: fn(*const $c_type) -> *const $crate::bindings::list_head = |p| {
// SAFETY: `p` is a valid pointer to `$c_type`.
- unsafe { &raw const (*p).$($field).+ }
+ &raw const (*p).$($field).+
};
// Calculate offset and create `CList`.
const OFFSET: usize = ::core::mem::offset_of!($c_type, $($field).+);
// SAFETY: The caller of this macro is responsible for ensuring safety.
- unsafe { $crate::interop::list::CList::<$rust_type, OFFSET>::from_raw($head) }
- }};
+ $crate::interop::list::CList::<$rust_type, OFFSET>::from_raw($head)
+ } }});
}
pub use clist_create;
--
2.34.1
^ permalink raw reply related [flat|nested] 32+ messages in thread* Re: [PATCH v13 1/1] rust: interop: Add list module for C linked list interface
2026-03-18 19:24 ` Joel Fernandes
@ 2026-03-19 11:59 ` Alexandre Courbot
0 siblings, 0 replies; 32+ messages in thread
From: Alexandre Courbot @ 2026-03-19 11:59 UTC (permalink / raw)
To: Joel Fernandes
Cc: Miguel Ojeda, Alejandra González, Alice Ryhl, linux-kernel,
Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Alex Gaynor,
Danilo Krummrich, Dave Airlie, David Airlie, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Simona Vetter, Daniel Almeida,
Koen Koning, Nikola Djukic, Philipp Stanner, Elle Rhumsaa,
Jonathan Corbet, Alex Deucher, Christian König, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, Huang Rui,
Matthew Auld, Matthew Brost, Lucas De Marchi,
Thomas Hellström, Helge Deller, John Hubbard,
Alistair Popple, Timur Tabi, Edwin Peer, Andrea Righi,
Andy Ritger, Zhi Wang, Balbir Singh, alexeyi, Eliot Courtney,
dri-devel, rust-for-linux, linux-doc, amd-gfx, intel-gfx,
intel-xe, linux-fbdev
On Thu Mar 19, 2026 at 4:24 AM JST, Joel Fernandes wrote:
> On Wed, Mar 18, 2026 at 07:57:14PM +0100, Miguel Ojeda wrote:
>> On Wed, Mar 18, 2026 at 7:31 PM Joel Fernandes <joelagnelf@nvidia.com> wrote:
>> >
>> > Anyway, the fix is simple, just need to do // SAFETY*: as Miguel suggests
>> > here, instead of // SAFETY:
>> > https://lore.kernel.org/all/CANiq72kEnDyUpnWMZmheJytjioeiJUK_C-yQJk77dPid89LExw@mail.gmail.com/
>>
>> So, to clarify, I suggested it as a temporary thing we could do if we
>> want to use that "fake `unsafe` block in macro matcher" pattern more
>> and more.
>>
>> i.e. if we plan to use the pattern more, then I am happy to ask
>> upstream if it would make sense for Clippy to recognize it (or perhaps
>> it is just a false negative instead of a false positive, given
>> `impl_device_context_deref`), so that we don't need a hacked safety
>> tag (Cc'ing Alejandra).
>>
>> But if we could put it outside, then we wouldn't need any of that.
>> Unsafe macros support could help perhaps here, which I have had it in
>> our wishlist too (https://github.com/Rust-for-Linux/linux/issues/354),
>> but I guess the fake block could still be useful to make only certain
>> macro arms unsafe? (Perhaps Rust could allow `unsafe` just at the
>> start of each arm for that...).
>
> Even if I reworked the macro to be outisde, it doesn't work as below, still
> need the 'disabled' comment on the macro's generate unsafe { } block below.
>
> If we don't want the SAFETY*: hack, we could do the following.
>
> Perhaps, we can file the github bug and also do the below. Once the
> github bug is fixed, we could remove the 'disable lint' below.
>
> Thoughts?
>
> ---8<-----------------------
>
> diff --git a/rust/kernel/interop/list.rs b/rust/kernel/interop/list.rs
> index 495497f0405e..dfa2e1490202 100644
> --- a/rust/kernel/interop/list.rs
> +++ b/rust/kernel/interop/list.rs
> @@ -73,7 +73,7 @@
> //!
> //!
> //! // Create typed [`CList`] from sentinel head.
> -//! // SAFETY*: `head` is valid and initialized, items are `SampleItemC` with
> +//! // SAFETY: `head` is valid and initialized, items are `SampleItemC` with
> //! // embedded `link` field, and `Item` is `#[repr(transparent)]` over `SampleItemC`.
> //! let list = clist_create!(unsafe { head, Item, SampleItemC, link });
> //!
> @@ -328,17 +328,19 @@ impl<'a, T, const OFFSET: usize> FusedIterator for CListIter<'a, T, OFFSET> {}
> /// Refer to the examples in the [`crate::interop::list`] module documentation.
> #[macro_export]
> macro_rules! clist_create {
> - (unsafe { $head:ident, $rust_type:ty, $c_type:ty, $($field:tt).+ }) => {{
> + (unsafe { $head:ident, $rust_type:ty, $c_type:ty, $($field:tt).+ }) => (
> + // SAFETY: disable lint.
> + unsafe { {{
> // Compile-time check that field path is a `list_head`.
> let _: fn(*const $c_type) -> *const $crate::bindings::list_head = |p| {
> // SAFETY: `p` is a valid pointer to `$c_type`.
> - unsafe { &raw const (*p).$($field).+ }
> + &raw const (*p).$($field).+
> };
>
> // Calculate offset and create `CList`.
> const OFFSET: usize = ::core::mem::offset_of!($c_type, $($field).+);
> // SAFETY: The caller of this macro is responsible for ensuring safety.
> - unsafe { $crate::interop::list::CList::<$rust_type, OFFSET>::from_raw($head) }
> - }};
> + $crate::interop::list::CList::<$rust_type, OFFSET>::from_raw($head)
> + } }});
> }
> pub use clist_create;
I think I like this, it preserves the expected use of `SAFETY:` without
that confusing `*`. The unsafe blocks is a bit larger that it should, be
we are in a controlled environment.
Even after using the `SAFETY*:` I was still getting errors because the
in-macro SAFETY comment wasn't at the right place:
warning: unsafe block missing a safety comment
--> ../rust/kernel/interop/list.rs:335:17
|
335 | |p| unsafe { &raw const (*p).$($field).+ };
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
::: ../rust/kernel/gpu/buddy.rs:527:21
|
527 | let clist = clist_create!(unsafe {
| _____________________-
528 | | head,
529 | | Block,
530 | | bindings::gpu_buddy_block,
531 | | __bindgen_anon_1.link
532 | | });
| |__________- in this macro invocation
The diff below fixes that, but I believe your proposal should as well on
top of letting callers use the expected SAFETY statement.
--- a/rust/kernel/interop/list.rs
+++ b/rust/kernel/interop/list.rs
@@ -330,8 +330,8 @@ impl<'a, T, const OFFSET: usize> FusedIterator for CListIter<'a, T, OFFSET> {}
macro_rules! clist_create {
(unsafe { $head:ident, $rust_type:ty, $c_type:ty, $($field:tt).+ }) => {{
// Compile-time check that field path is a `list_head`.
- // SAFETY: `p` is a valid pointer to `$c_type`.
let _: fn(*const $c_type) -> *const $crate::bindings::list_head =
+ // SAFETY: `p` is a valid pointer to `$c_type`.
|p| unsafe { &raw const (*p).$($field).+ };
// Calculate offset and create `CList`.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v13 1/1] rust: interop: Add list module for C linked list interface
2026-03-18 18:57 ` Miguel Ojeda
2026-03-18 19:24 ` Joel Fernandes
@ 2026-03-23 0:07 ` Alejandra González
1 sibling, 0 replies; 32+ messages in thread
From: Alejandra González @ 2026-03-23 0:07 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Joel Fernandes, Alice Ryhl, linux-kernel, Miguel Ojeda,
Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Andreas Hindborg, Trevor Gross, Alex Gaynor, Danilo Krummrich,
Dave Airlie, David Airlie, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Simona Vetter, Daniel Almeida, Koen Koning,
Nikola Djukic, Alexandre Courbot, Philipp Stanner, Elle Rhumsaa,
Jonathan Corbet, Alex Deucher, Christian König, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, Huang Rui,
Matthew Auld, Matthew Brost, Lucas De Marchi,
Thomas Hellström, Helge Deller, John Hubbard,
Alistair Popple, Timur Tabi, Edwin Peer, Andrea Righi,
Andy Ritger, Zhi Wang, Balbir Singh, alexeyi, Eliot Courtney,
dri-devel, rust-for-linux, linux-doc, amd-gfx, intel-gfx,
intel-xe, linux-fbdev
On Wed, Mar 18, 2026 at 7:57 PM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> On Wed, Mar 18, 2026 at 7:31 PM Joel Fernandes <joelagnelf@nvidia.com> wrote:
> >
> > Anyway, the fix is simple, just need to do // SAFETY*: as Miguel suggests
> > here, instead of // SAFETY:
> > https://lore.kernel.org/all/CANiq72kEnDyUpnWMZmheJytjioeiJUK_C-yQJk77dPid89LExw@mail.gmail.com/
>
> So, to clarify, I suggested it as a temporary thing we could do if we
> want to use that "fake `unsafe` block in macro matcher" pattern more
> and more.
>
> i.e. if we plan to use the pattern more, then I am happy to ask
> upstream if it would make sense for Clippy to recognize it (or perhaps
> it is just a false negative instead of a false positive, given
> `impl_device_context_deref`), so that we don't need a hacked safety
> tag (Cc'ing Alejandra).
The team is a bit hesitant on adding comment-specific syntax apart
from the widely used (and already on clippy) `// SAFETY` comments.
I'm pushing for some more comments specific to the Rust4Linux project,
because we already tailor some lints for specific projects (such as the
Safety Critical Rust Consortium), but adding more than new types of
comments is a bit much.
On this specific lint emission, I'll see if I can get it fixed,
because it's a false
positive.
Cheers,
Alejandra.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH v13 1/1] rust: interop: Add list module for C linked list interface
2026-03-17 20:17 ` [PATCH v13 1/1] " Joel Fernandes
` (2 preceding siblings ...)
2026-03-18 12:40 ` Alice Ryhl
@ 2026-03-19 11:39 ` Gary Guo
2026-03-19 12:05 ` Danilo Krummrich
3 siblings, 1 reply; 32+ messages in thread
From: Gary Guo @ 2026-03-19 11:39 UTC (permalink / raw)
To: Joel Fernandes, linux-kernel
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Alex Gaynor, Danilo Krummrich, Dave Airlie, David Airlie,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Simona Vetter, Daniel Almeida, Koen Koning, Nikola Djukic,
Alexandre Courbot, Philipp Stanner, Elle Rhumsaa, Jonathan Corbet,
Alex Deucher, Christian König, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellström,
Helge Deller, John Hubbard, Alistair Popple, Timur Tabi,
Edwin Peer, Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh,
alexeyi, Eliot Courtney, dri-devel, rust-for-linux, linux-doc,
amd-gfx, intel-gfx, intel-xe, linux-fbdev
On Tue Mar 17, 2026 at 8:17 PM GMT, Joel Fernandes wrote:
> Add a new module `kernel::interop::list` 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>
> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
> Acked-by: Alexandre Courbot <acourbot@nvidia.com>
> Acked-by: Gary Guo <gary@garyguo.net>
> Acked-by: Miguel Ojeda <ojeda@kernel.org>
> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
> ---
> MAINTAINERS | 8 +
> rust/helpers/helpers.c | 1 +
> rust/helpers/list.c | 17 ++
> rust/kernel/interop.rs | 9 +
> rust/kernel/interop/list.rs | 342 ++++++++++++++++++++++++++++++++++++
> rust/kernel/lib.rs | 2 +
> 6 files changed, 379 insertions(+)
> create mode 100644 rust/helpers/list.c
> create mode 100644 rust/kernel/interop.rs
> create mode 100644 rust/kernel/interop/list.rs
>
> +/// 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
> +///
> +/// The caller must ensure:
> +///
> +/// - `$head` is a valid, initialized sentinel `list_head` (e.g. via `INIT_LIST_HEAD()`)
> +/// pointing to a list that is not concurrently modified for the lifetime of the [`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 the [`crate::interop::list`] module documentation.
> +#[macro_export]
> +macro_rules! clist_create {
> + (unsafe { $head:ident, $rust_type:ty, $c_type:ty, $($field:tt).+ }) => {{
> + // Compile-time check that field path is a `list_head`.
> + // SAFETY: `p` is a valid pointer to `$c_type`.
> + let _: fn(*const $c_type) -> *const $crate::bindings::list_head =
> + |p| unsafe { &raw const (*p).$($field).+ };
Actually, this check is insufficient, you should create a reference instead
(just in case people put this inside `repr(packed)`.
This could be something like
let _ = |p: &$c_type| { _ = &p.$($field).+ }
?
> +
> + // Calculate offset and create `CList`.
> + const OFFSET: usize = ::core::mem::offset_of!($c_type, $($field).+);
> + // SAFETY: The caller of this macro is responsible for ensuring safety.
> + unsafe { $crate::interop::list::CList::<$rust_type, OFFSET>::from_raw($head) }
Given that this is unsafe, I am not sure why the macro should have unsafe
keyword in it, rather than just being `clist_create(a, b, c, d)` and just have
user write unsafe.
The offset could probably benefit from similar strategies we used for other
embedded data structure like Rust list and work items. Boqun has a series
unifying these and clist could probably use it, too. (As a follow-up)
Best,
Gary
> + }};
> +}
> diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
> index d93292d47420..bdcf632050ee 100644
> --- a/rust/kernel/lib.rs
> +++ b/rust/kernel/lib.rs
> @@ -29,6 +29,7 @@
> #![feature(lint_reasons)]
> //
> // Stable since Rust 1.82.0.
> +#![feature(offset_of_nested)]
> #![feature(raw_ref_op)]
> //
> // Stable since Rust 1.83.0.
> @@ -107,6 +108,7 @@
> #[doc(hidden)]
> pub mod impl_flags;
> pub mod init;
> +pub mod interop;
> pub mod io;
> pub mod ioctl;
> pub mod iommu;
G
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH v13 1/1] rust: interop: Add list module for C linked list interface
2026-03-19 11:39 ` Gary Guo
@ 2026-03-19 12:05 ` Danilo Krummrich
2026-03-19 12:21 ` Gary Guo
0 siblings, 1 reply; 32+ messages in thread
From: Danilo Krummrich @ 2026-03-19 12:05 UTC (permalink / raw)
To: Gary Guo
Cc: Joel Fernandes, linux-kernel, Miguel Ojeda, Boqun Feng,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Alex Gaynor, Dave Airlie, David Airlie,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Simona Vetter, Daniel Almeida, Koen Koning, Nikola Djukic,
Alexandre Courbot, Philipp Stanner, Elle Rhumsaa, Jonathan Corbet,
Alex Deucher, Christian König, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellström,
Helge Deller, John Hubbard, Alistair Popple, Timur Tabi,
Edwin Peer, Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh,
alexeyi, Eliot Courtney, dri-devel, rust-for-linux, linux-doc,
amd-gfx, intel-gfx, intel-xe, linux-fbdev
On Thu Mar 19, 2026 at 12:39 PM CET, Gary Guo wrote:
> On Tue Mar 17, 2026 at 8:17 PM GMT, Joel Fernandes wrote:
>> Add a new module `kernel::interop::list` 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>
>> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
>> Acked-by: Alexandre Courbot <acourbot@nvidia.com>
>> Acked-by: Gary Guo <gary@garyguo.net>
>> Acked-by: Miguel Ojeda <ojeda@kernel.org>
>> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
>> ---
>> MAINTAINERS | 8 +
>> rust/helpers/helpers.c | 1 +
>> rust/helpers/list.c | 17 ++
>> rust/kernel/interop.rs | 9 +
>> rust/kernel/interop/list.rs | 342 ++++++++++++++++++++++++++++++++++++
>> rust/kernel/lib.rs | 2 +
>> 6 files changed, 379 insertions(+)
>> create mode 100644 rust/helpers/list.c
>> create mode 100644 rust/kernel/interop.rs
>> create mode 100644 rust/kernel/interop/list.rs
>>
>> +/// 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
>> +///
>> +/// The caller must ensure:
>> +///
>> +/// - `$head` is a valid, initialized sentinel `list_head` (e.g. via `INIT_LIST_HEAD()`)
>> +/// pointing to a list that is not concurrently modified for the lifetime of the [`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 the [`crate::interop::list`] module documentation.
>> +#[macro_export]
>> +macro_rules! clist_create {
>> + (unsafe { $head:ident, $rust_type:ty, $c_type:ty, $($field:tt).+ }) => {{
>> + // Compile-time check that field path is a `list_head`.
>> + // SAFETY: `p` is a valid pointer to `$c_type`.
>> + let _: fn(*const $c_type) -> *const $crate::bindings::list_head =
>> + |p| unsafe { &raw const (*p).$($field).+ };
>
> Actually, this check is insufficient, you should create a reference instead
> (just in case people put this inside `repr(packed)`.
>
> This could be something like
>
> let _ = |p: &$c_type| { _ = &p.$($field).+ }
>
> ?
>
>> +
>> + // Calculate offset and create `CList`.
>> + const OFFSET: usize = ::core::mem::offset_of!($c_type, $($field).+);
>> + // SAFETY: The caller of this macro is responsible for ensuring safety.
>> + unsafe { $crate::interop::list::CList::<$rust_type, OFFSET>::from_raw($head) }
>
> Given that this is unsafe, I am not sure why the macro should have unsafe
> keyword in it, rather than just being `clist_create(a, b, c, d)` and just have
> user write unsafe.
Either you are proposing to not wrap unsafe code within unsafe {} within the
macro, such that the user is forced to write an unsafe {} around the macro, but
then they calls within the macro are not justified individually, or you propose
to let the user write an unsafe {} around the macro regardless of the inner
unsafe {} blocks, but then then the compiler warns about an unnecessary unsafe
and nothing forces the user to actually wrap it in unsafe {}.
Is there a third option I'm not aware of? I.e. for the above reason
impl_device_context_deref!() was designed the same way.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/rust/kernel/device.rs#n650
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH v13 1/1] rust: interop: Add list module for C linked list interface
2026-03-19 12:05 ` Danilo Krummrich
@ 2026-03-19 12:21 ` Gary Guo
2026-03-19 12:51 ` Danilo Krummrich
2026-03-19 16:56 ` Joel Fernandes
0 siblings, 2 replies; 32+ messages in thread
From: Gary Guo @ 2026-03-19 12:21 UTC (permalink / raw)
To: Danilo Krummrich, Gary Guo
Cc: Joel Fernandes, linux-kernel, Miguel Ojeda, Boqun Feng,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Alex Gaynor, Dave Airlie, David Airlie,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Simona Vetter, Daniel Almeida, Koen Koning, Nikola Djukic,
Alexandre Courbot, Philipp Stanner, Elle Rhumsaa, Jonathan Corbet,
Alex Deucher, Christian König, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellström,
Helge Deller, John Hubbard, Alistair Popple, Timur Tabi,
Edwin Peer, Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh,
alexeyi, Eliot Courtney, dri-devel, rust-for-linux, linux-doc,
amd-gfx, intel-gfx, intel-xe, linux-fbdev
On Thu Mar 19, 2026 at 12:05 PM GMT, Danilo Krummrich wrote:
> On Thu Mar 19, 2026 at 12:39 PM CET, Gary Guo wrote:
>> On Tue Mar 17, 2026 at 8:17 PM GMT, Joel Fernandes wrote:
>>> Add a new module `kernel::interop::list` 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>
>>> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
>>> Acked-by: Alexandre Courbot <acourbot@nvidia.com>
>>> Acked-by: Gary Guo <gary@garyguo.net>
>>> Acked-by: Miguel Ojeda <ojeda@kernel.org>
>>> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
>>> ---
>>> MAINTAINERS | 8 +
>>> rust/helpers/helpers.c | 1 +
>>> rust/helpers/list.c | 17 ++
>>> rust/kernel/interop.rs | 9 +
>>> rust/kernel/interop/list.rs | 342 ++++++++++++++++++++++++++++++++++++
>>> rust/kernel/lib.rs | 2 +
>>> 6 files changed, 379 insertions(+)
>>> create mode 100644 rust/helpers/list.c
>>> create mode 100644 rust/kernel/interop.rs
>>> create mode 100644 rust/kernel/interop/list.rs
>>>
>>> +/// 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
>>> +///
>>> +/// The caller must ensure:
>>> +///
>>> +/// - `$head` is a valid, initialized sentinel `list_head` (e.g. via `INIT_LIST_HEAD()`)
>>> +/// pointing to a list that is not concurrently modified for the lifetime of the [`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 the [`crate::interop::list`] module documentation.
>>> +#[macro_export]
>>> +macro_rules! clist_create {
>>> + (unsafe { $head:ident, $rust_type:ty, $c_type:ty, $($field:tt).+ }) => {{
>>> + // Compile-time check that field path is a `list_head`.
>>> + // SAFETY: `p` is a valid pointer to `$c_type`.
>>> + let _: fn(*const $c_type) -> *const $crate::bindings::list_head =
>>> + |p| unsafe { &raw const (*p).$($field).+ };
>>
>> Actually, this check is insufficient, you should create a reference instead
>> (just in case people put this inside `repr(packed)`.
>>
>> This could be something like
>>
>> let _ = |p: &$c_type| { _ = &p.$($field).+ }
>>
>> ?
>>
>>> +
>>> + // Calculate offset and create `CList`.
>>> + const OFFSET: usize = ::core::mem::offset_of!($c_type, $($field).+);
>>> + // SAFETY: The caller of this macro is responsible for ensuring safety.
>>> + unsafe { $crate::interop::list::CList::<$rust_type, OFFSET>::from_raw($head) }
>>
>> Given that this is unsafe, I am not sure why the macro should have unsafe
>> keyword in it, rather than just being `clist_create(a, b, c, d)` and just have
>> user write unsafe.
>
> Either you are proposing to not wrap unsafe code within unsafe {} within the
> macro, such that the user is forced to write an unsafe {} around the macro, but
> then they calls within the macro are not justified individually, or you propose
> to let the user write an unsafe {} around the macro regardless of the inner
> unsafe {} blocks, but then then the compiler warns about an unnecessary unsafe
> and nothing forces the user to actually wrap it in unsafe {}.
The former.
"The caller of this macro is responsible for ensuring safety" justification is
not really useful here IMO.
If there're cases where we do want to justify unsafe code that's not immediately
deferring to the user inside the macro, we could use the SAFETY* trick proposed
in the thread, without writing an actual `unsafe {}` block.
>
> Is there a third option I'm not aware of? I.e. for the above reason
> impl_device_context_deref!() was designed the same way.
impl_device_context_deref!() expands to an item, so the user couldn't put an
`unsafe {}` on the outside. This macro expands to an expression, so users can
add `unsafe` themselves.
Best,
Gary
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/rust/kernel/device.rs#n650
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH v13 1/1] rust: interop: Add list module for C linked list interface
2026-03-19 12:21 ` Gary Guo
@ 2026-03-19 12:51 ` Danilo Krummrich
2026-03-19 16:56 ` Joel Fernandes
1 sibling, 0 replies; 32+ messages in thread
From: Danilo Krummrich @ 2026-03-19 12:51 UTC (permalink / raw)
To: Gary Guo
Cc: Joel Fernandes, linux-kernel, Miguel Ojeda, Boqun Feng,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Alex Gaynor, Dave Airlie, David Airlie,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Simona Vetter, Daniel Almeida, Koen Koning, Nikola Djukic,
Alexandre Courbot, Philipp Stanner, Elle Rhumsaa, Jonathan Corbet,
Alex Deucher, Christian König, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellström,
Helge Deller, John Hubbard, Alistair Popple, Timur Tabi,
Edwin Peer, Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh,
alexeyi, Eliot Courtney, dri-devel, rust-for-linux, linux-doc,
amd-gfx, intel-gfx, intel-xe, linux-fbdev
On Thu Mar 19, 2026 at 1:21 PM CET, Gary Guo wrote:
> If there're cases where we do want to justify unsafe code that's not immediately
> deferring to the user inside the macro, we could use the SAFETY* trick proposed
> in the thread, without writing an actual `unsafe {}` block.
Works for me -- if this is what we want to do in such cases, we should probably
document it somewhere in the coding guidelines.
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [PATCH v13 1/1] rust: interop: Add list module for C linked list interface
2026-03-19 12:21 ` Gary Guo
2026-03-19 12:51 ` Danilo Krummrich
@ 2026-03-19 16:56 ` Joel Fernandes
1 sibling, 0 replies; 32+ messages in thread
From: Joel Fernandes @ 2026-03-19 16:56 UTC (permalink / raw)
To: Gary Guo, Danilo Krummrich
Cc: linux-kernel, Miguel Ojeda, Boqun Feng, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Alex Gaynor, Dave Airlie, David Airlie, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Simona Vetter, Daniel Almeida,
Koen Koning, Nikola Djukic, Alexandre Courbot, Philipp Stanner,
Elle Rhumsaa, Jonathan Corbet, Alex Deucher, Christian König,
Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
Huang Rui, Matthew Auld, Matthew Brost, Lucas De Marchi,
Thomas Hellström, Helge Deller, John Hubbard,
Alistair Popple, Timur Tabi, Edwin Peer, Andrea Righi,
Andy Ritger, Zhi Wang, Balbir Singh, alexeyi, Eliot Courtney,
dri-devel, rust-for-linux, linux-doc, amd-gfx, intel-gfx,
intel-xe, linux-fbdev
On 3/19/2026 8:21 AM, Gary Guo wrote:
> On Thu Mar 19, 2026 at 12:05 PM GMT, Danilo Krummrich wrote:
>> On Thu Mar 19, 2026 at 12:39 PM CET, Gary Guo wrote:
>>> On Tue Mar 17, 2026 at 8:17 PM GMT, Joel Fernandes wrote:
>>>> Add a new module `kernel::interop::list` 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>
>>>> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
>>>> Acked-by: Alexandre Courbot <acourbot@nvidia.com>
>>>> Acked-by: Gary Guo <gary@garyguo.net>
>>>> Acked-by: Miguel Ojeda <ojeda@kernel.org>
>>>> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
>>>> ---
>>>> MAINTAINERS | 8 +
>>>> rust/helpers/helpers.c | 1 +
>>>> rust/helpers/list.c | 17 ++
>>>> rust/kernel/interop.rs | 9 +
>>>> rust/kernel/interop/list.rs | 342 ++++++++++++++++++++++++++++++++++++
>>>> rust/kernel/lib.rs | 2 +
>>>> 6 files changed, 379 insertions(+)
>>>> create mode 100644 rust/helpers/list.c
>>>> create mode 100644 rust/kernel/interop.rs
>>>> create mode 100644 rust/kernel/interop/list.rs
>>>>
>>>> +/// 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
>>>> +///
>>>> +/// The caller must ensure:
>>>> +///
>>>> +/// - `$head` is a valid, initialized sentinel `list_head` (e.g. via `INIT_LIST_HEAD()`)
>>>> +/// pointing to a list that is not concurrently modified for the lifetime of the [`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 the [`crate::interop::list`] module documentation.
>>>> +#[macro_export]
>>>> +macro_rules! clist_create {
>>>> + (unsafe { $head:ident, $rust_type:ty, $c_type:ty, $($field:tt).+ }) => {{
>>>> + // Compile-time check that field path is a `list_head`.
>>>> + // SAFETY: `p` is a valid pointer to `$c_type`.
>>>> + let _: fn(*const $c_type) -> *const $crate::bindings::list_head =
>>>> + |p| unsafe { &raw const (*p).$($field).+ };
>>>
>>> Actually, this check is insufficient, you should create a reference instead
>>> (just in case people put this inside `repr(packed)`.
>>>
>>> This could be something like
>>>
>>> let _ = |p: &$c_type| { _ = &p.$($field).+ }
>>>
>>> ?
>>>
>>>> +
>>>> + // Calculate offset and create `CList`.
>>>> + const OFFSET: usize = ::core::mem::offset_of!($c_type, $($field).+);
>>>> + // SAFETY: The caller of this macro is responsible for ensuring safety.
>>>> + unsafe { $crate::interop::list::CList::<$rust_type, OFFSET>::from_raw($head) }
>>>
>>> Given that this is unsafe, I am not sure why the macro should have unsafe
>>> keyword in it, rather than just being `clist_create(a, b, c, d)` and just have
>>> user write unsafe.
>>
>> Either you are proposing to not wrap unsafe code within unsafe {} within the
>> macro, such that the user is forced to write an unsafe {} around the macro, but
>> then they calls within the macro are not justified individually, or you propose
>> to let the user write an unsafe {} around the macro regardless of the inner
>> unsafe {} blocks, but then then the compiler warns about an unnecessary unsafe
>> and nothing forces the user to actually wrap it in unsafe {}.
>
> The former.
>
> "The caller of this macro is responsible for ensuring safety" justification is
> not really useful here IMO.
>
> If there're cases where we do want to justify unsafe code that's not immediately
> deferring to the user inside the macro, we could use the SAFETY* trick proposed
> in the thread, without writing an actual `unsafe {}` block.
>
>>
>> Is there a third option I'm not aware of? I.e. for the above reason
>> impl_device_context_deref!() was designed the same way.
>
> impl_device_context_deref!() expands to an item, so the user couldn't put an
> `unsafe {}` on the outside. This macro expands to an expression, so users can
> add `unsafe` themselves.
>
I like Gary's idea. I will drop the unsafe { } blocks within the macro and
we can force the caller to clear the lint. That's the cleanest and most
reasonable IMO, instead of working around the linter.
Unless someone yells, this is what I'll do for the next iteration.
--
Joel Fernandes
^ permalink raw reply [flat|nested] 32+ messages in thread