[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55706e62-83ce-41d8-b0b8-320955cd73bc@nvidia.com>
Date: Mon, 1 Dec 2025 16:35:40 -0500
From: Joel Fernandes <joelagnelf@...dia.com>
To: Alice Ryhl <aliceryhl@...gle.com>
Cc: linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org,
dri-devel@...ts.freedesktop.org, nouveau@...ts.freedesktop.org,
Danilo Krummrich <dakr@...nel.org>, Dave Airlie <airlied@...il.com>,
Alexandre Courbot <acourbot@...dia.com>, Alistair Popple
<apopple@...dia.com>, Miguel Ojeda <ojeda@...nel.org>,
Alex Gaynor <alex.gaynor@...il.com>, Boqun Feng <boqun.feng@...il.com>,
Gary Guo <gary@...yguo.net>, bjorn3_gh@...tonmail.com,
Benno Lossin <lossin@...nel.org>, Andreas Hindborg <a.hindborg@...nel.org>,
Trevor Gross <tmgross@...ch.edu>, Simona Vetter <simona@...ll.ch>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
John Hubbard <jhubbard@...dia.com>, Timur Tabi <ttabi@...dia.com>,
Joel Fernandes <joel@...lfernandes.org>,
Lyude Paul <elle@...thered-steel.dev>,
Daniel Almeida <daniel.almeida@...labora.com>,
Andrea Righi <arighi@...dia.com>, Philipp Stanner <phasta@...nel.org>
Subject: Re: [PATCH v3] rust: clist: Add support to interface with C linked
lists
On 12/1/2025 10:25 AM, Alice Ryhl wrote:
> On Sat, Nov 29, 2025 at 04:30:56PM -0500, Joel Fernandes wrote:
>> Add a new module `clist` for working with C's doubly circular linked
>> lists. Provide low-level iteration over list_head nodes and high-level
>> iteration over typed list items.
>>
>> Provide a `clist_create` macro to assist in creation of the `Clist` type.
>>
[...]
>> +//! // Rust wrapper for the C struct.
>> +//! // The list item struct in this example is defined in C code as:
>> +//! // struct SampleItemC {
>> +//! // int value;
>> +//! // struct list_head link;
>> +//! // };
>> +//! //
>> +//! #[repr(transparent)]
>> +//! pub(crate) struct Item(Opaque<SampleItemC>);
>> +//!
>> +//! impl Item {
>> +//! pub(crate) fn value(&self) -> i32 {
>> +//! // SAFETY: `Item` has same layout as `SampleItemC`.
>> +//! unsafe { (*self.0.get()).value }
>> +//! }
>> +//! }
>> +//!
>> +//! // Create typed Clist from sentinel head.
>> +//! // SAFETY: head is valid, items are `SampleItemC` with embedded `link` field.
>> +//! let list = unsafe { clist_create!(&mut head, Item, SampleItemC, link) };
>> +//!
>> +//! // Iterate directly over typed items.
>> +//! let mut found_0 = false;
>> +//! let mut found_10 = false;
>> +//! let mut found_20 = false;
>> +//!
>> +//! for item in list.iter() {
>> +//! let val = item.value();
>> +//! if val == 0 { found_0 = true; }
>> +//! if val == 10 { found_10 = true; }
>> +//! if val == 20 { found_20 = true; }
>> +//! }
>> +//!
>> +//! assert!(found_0 && found_10 && found_20);
>> +//! ```
>> +
>> +use core::{
>> + iter::FusedIterator,
>> + marker::PhantomData, //
>> +};
>> +
>> +use crate::{
>> + bindings,
>> + types::Opaque, //
>> +};
>> +
>> +/// Initialize a `list_head` object to point to itself.
>> +///
>> +/// # Safety
>> +///
>> +/// `list` must be a valid pointer to a `list_head` object.
>> +#[inline]
>> +pub unsafe fn init_list_head(list: *mut bindings::list_head) {
>> + // SAFETY: Caller guarantees `list` is a valid pointer to a `list_head`.
>> + unsafe {
>> + (*list).next = list;
>> + (*list).prev = list;
>> + }
>> +}
>
> It may make sense to move such manual reimplementations into the
> bindings crate so that other abstractions take advantage of them by
> default when they write bindings::init_list_head.
>
> Of course you can still have a re-export here.
>
Where would we make this change, do you mean to rust/helpers/ and have it come
into the bindings that (like i did in v2)? Or do you mean move this function as
it is to bindings/lib.rs?
I am Ok with either.
>> +/// Wraps a `list_head` object for use in intrusive linked lists.
>> +///
>> +/// # Invariants
>> +///
>> +/// - `ClistHead` represents an allocated and valid `list_head` structure.
>> +///
>> +/// # Safety
>> +///
>> +/// - All `list_head` nodes must not be modified by C code for the lifetime of `ClistHead`.
>
> So if I modify the list from Rust code, it's okay?
>
> I think the actual requirement you want is just that nobody modifies it.
Yeah you're right, I will change the phrasing.
>
>> +#[repr(transparent)]
>> +pub struct ClistHead(Opaque<bindings::list_head>);
>> +
>> +impl ClistHead {
>> + /// Create a `&ClistHead` reference from a raw `list_head` pointer.
>> + ///
>> + /// # Safety
>> + ///
>> + /// - `ptr` must be a valid pointer to an allocated and initialized `list_head` structure.
>> + /// - `ptr` must remain valid and unmodified for the lifetime `'a`.
>> + #[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.
>> + unsafe { &*ptr.cast() }
>> + }
>> +
>> + /// Get the raw `list_head` pointer.
>> + #[inline]
>> + pub fn as_raw(&self) -> *mut bindings::list_head {
>> + self.0.get()
>> + }
>> +
>> + /// Get the next `ClistHead` in the list.
>> + #[inline]
>> + pub fn next(&self) -> &Self {
>> + let raw = self.as_raw();
>> + // SAFETY:
>> + // - `self.as_raw()` is valid per type invariants.
>> + // - The `next` pointer is guaranteed to be non-NULL.
>> + unsafe { Self::from_raw((*raw).next) }
>> + }
>> +
>> + /// Get the previous `ClistHead` in the list.
>> + #[inline]
>> + pub fn prev(&self) -> &Self {
>> + let raw = self.as_raw();
>> + // SAFETY:
>> + // - self.as_raw() is valid per type invariants.
>> + // - The `prev` pointer is guaranteed to be non-NULL.
>> + unsafe { Self::from_raw((*raw).prev) }
>> + }
>> +
>> + /// 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 }
>> + }
>> +}
>> +
>> +// SAFETY: `ClistHead` can be sent to any thread.
>> +unsafe impl Send for ClistHead {}
>> +
>> +// SAFETY: `ClistHead` can be shared among threads as it is not modified by C per type invariants.
>> +unsafe impl Sync for ClistHead {}
>> +
>> +impl PartialEq for ClistHead {
>> + fn eq(&self, other: &Self) -> bool {
>> + self.as_raw() == other.as_raw()
>> + }
>> +}
>> +
[...]
>> +impl<'a> FusedIterator for ClistHeadIter<'a> {}
>> +
>> +/// A typed C linked list with a sentinel head.
>> +///
>> +/// A sentinel head represents the entire linked list and can be used for
>> +/// iteration over items of type `T`, it is not associated with a specific item.
>> +///
>> +/// # Invariants
>> +///
>> +/// - `head` is an allocated and valid C `list_head` structure that is the list's sentinel.
>> +/// - `offset` is the byte offset of the `list_head` field within the C struct that `T` wraps.
>> +///
>> +/// # Safety
>> +///
>> +/// - All the list's `list_head` nodes must be allocated and have valid next/prev pointers.
>> +/// - The underlying `list_head` (and entire list) must not be modified by C for the
>> +/// lifetime 'a of `Clist`.
>
> Here and elsewhere: We don't generally have Safety sections on structs.
> It looks like these should just be invariants.
I see, Ok I will move it, thanks.
>
>> +pub struct Clist<'a, T> {
>> + head: &'a ClistHead,
>> + offset: usize,
>> + _phantom: PhantomData<&'a T>,
>> +}
>> +
>> +impl<'a, T> Clist<'a, T> {
>> + /// Create a typed `Clist` from a raw sentinel `list_head` pointer.
>> + ///
>> + /// The const generic `OFFSET` specifies the byte offset of the `list_head` field within
>> + /// the C struct that `T` wraps.
>> + ///
>> + /// # Safety
>> + ///
>> + /// - `ptr` must be a valid pointer to an allocated and initialized `list_head` structure
>> + /// representing a list sentinel.
>> + /// - `ptr` must remain valid and unmodified for the lifetime `'a`.
>> + /// - The list must contain items where the `list_head` field is at byte offset `OFFSET`.
>> + /// - `T` must be `#[repr(transparent)]` over the C struct.
>> + #[inline]
>> + pub unsafe fn from_raw_and_offset<const OFFSET: usize>(ptr: *mut bindings::list_head) -> Self {
>
> I think OFFSET should probably be a constant on the struct rather than a
> field.
Yes John suggested this too. The type signature becomes complex/ugly (and you
guys know my hatred for const generic syntax :)). But ok, since this is mostly
hidden by a macro, I will make the change :).
>
>> + Self {
>> + // SAFETY: Caller guarantees `ptr` is a valid, sentinel `list_head` object.
>> + head: unsafe { ClistHead::from_raw(ptr) },
>> + offset: OFFSET,
>> + _phantom: PhantomData,
>> + }
>> + }
>> +
>> + /// Get the raw sentinel `list_head` pointer.
>> + #[inline]
>> + pub fn as_raw(&self) -> *mut bindings::list_head {
>> + self.head.as_raw()
>> + }
>> +
>> + /// Check if the list is empty.
>> + #[inline]
>> + pub fn is_empty(&self) -> bool {
>> + let raw = self.as_raw();
>> + // SAFETY: self.as_raw() is valid per type invariants.
>> + unsafe { (*raw).next == raw }
>> + }
>> +
>> + /// Create an iterator over typed items.
>> + #[inline]
>> + pub fn iter(&self) -> ClistIter<'a, T> {
>> + ClistIter {
>> + head_iter: ClistHeadIter {
>> + current_head: self.head,
>> + list_head: self.head,
>> + exhausted: false,
>> + },
>> + offset: self.offset,
>> + _phantom: PhantomData,
>> + }
>> + }
>> +}
>> +
>> +/// High-level iterator over typed list items.
>> +pub struct ClistIter<'a, T> {
>> + head_iter: ClistHeadIter<'a>,
>> + offset: usize,
>> + _phantom: PhantomData<&'a T>,
>> +}
>> +
>> +impl<'a, T> Iterator for ClistIter<'a, T> {
>> + type Item = &'a T;
>> +
>> + fn next(&mut self) -> Option<Self::Item> {
>> + let head = self.head_iter.next()?;
>> +
>> + // Convert to item using offset.
>> + // SAFETY:
>> + // - `item_ptr` calculation from `offset` (calculated using offset_of!)
>> + // is valid per invariants.
>> + Some(unsafe { &*head.as_raw().cast::<u8>().sub(self.offset).cast::<T>() })
>
> Can be simplified to:
> head.as_raw().byte_sub(OFFSET).cast::<T>()
>
Fixed, thanks.
- Joel
Powered by blists - more mailing lists