mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Joel Fernandes <joelagnelf@nvidia.com>
To: Alice Ryhl <aliceryhl@google.com>
Cc: linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org,
	dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org,
	Danilo Krummrich <dakr@kernel.org>,
	Dave Airlie <airlied@gmail.com>,
	Alexandre Courbot <acourbot@nvidia.com>,
	Alistair Popple <apopple@nvidia.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	Alex Gaynor <alex.gaynor@gmail.com>,
	Boqun Feng <boqun.feng@gmail.com>, Gary Guo <gary@garyguo.net>,
	bjorn3_gh@protonmail.com, Benno Lossin <lossin@kernel.org>,
	Andreas Hindborg <a.hindborg@kernel.org>,
	Trevor Gross <tmgross@umich.edu>, Simona Vetter <simona@ffwll.ch>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	John Hubbard <jhubbard@nvidia.com>, Timur Tabi <ttabi@nvidia.com>,
	Joel Fernandes <joel@joelfernandes.org>,
	Lyude Paul <elle@weathered-steel.dev>,
	Daniel Almeida <daniel.almeida@collabora.com>,
	Andrea Righi <arighi@nvidia.com>,
	Philipp Stanner <phasta@kernel.org>
Subject: Re: [PATCH v3] rust: clist: Add support to interface with C linked lists
Date: Mon, 1 Dec 2025 16:35:40 -0500	[thread overview]
Message-ID: <55706e62-83ce-41d8-b0b8-320955cd73bc@nvidia.com> (raw)
In-Reply-To: <aS2zeUDqqbmYPaug@google.com>



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


  reply	other threads:[~2025-12-01 21:35 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-29 21:30 Joel Fernandes
2025-12-01  0:34 ` John Hubbard
2025-12-01 20:32   ` Joel Fernandes
2025-12-01 20:57     ` Joel Fernandes
2025-12-01 22:17     ` John Hubbard
2025-12-01 22:43       ` Joel Fernandes
2025-12-01 22:52         ` John Hubbard
2025-12-01 23:09           ` Joel Fernandes
2025-12-01 23:15             ` John Hubbard
2025-12-01 23:21               ` Joel Fernandes
2025-12-01 22:58         ` Miguel Ojeda
2025-12-01 22:50       ` Miguel Ojeda
2025-12-01 22:54         ` John Hubbard
2025-12-01 15:25 ` Alice Ryhl
2025-12-01 21:35   ` Joel Fernandes [this message]
2025-12-01 16:51 ` Daniel Almeida
2025-12-01 19:35   ` John Hubbard
2025-12-01 20:06     ` Joel Fernandes
2025-12-01 23:01       ` Daniel Almeida
2025-12-01 23:23         ` Joel Fernandes
2025-12-01 22:54     ` Daniel Almeida
2025-12-01 22:58       ` Miguel Ojeda
2025-12-01 21:46   ` Joel Fernandes
2025-12-03 13:06 ` Alexandre Courbot
2025-12-03 15:08   ` Joel Fernandes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55706e62-83ce-41d8-b0b8-320955cd73bc@nvidia.com \
    --to=joelagnelf@nvidia.com \
    --cc=a.hindborg@kernel.org \
    --cc=acourbot@nvidia.com \
    --cc=airlied@gmail.com \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=apopple@nvidia.com \
    --cc=arighi@nvidia.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=dakr@kernel.org \
    --cc=daniel.almeida@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=elle@weathered-steel.dev \
    --cc=gary@garyguo.net \
    --cc=jhubbard@nvidia.com \
    --cc=joel@joelfernandes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=nouveau@lists.freedesktop.org \
    --cc=ojeda@kernel.org \
    --cc=phasta@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=simona@ffwll.ch \
    --cc=tmgross@umich.edu \
    --cc=ttabi@nvidia.com \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®