[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87o6smf0no.fsf@t14s.mail-host-address-is-not-set>
Date: Mon, 11 Aug 2025 15:28:11 +0200
From: Andreas Hindborg <a.hindborg@...nel.org>
To: Tamir Duberstein <tamird@...il.com>, Miguel Ojeda <ojeda@...nel.org>,
Alex Gaynor <alex.gaynor@...il.com>, Boqun Feng <boqun.feng@...il.com>,
Gary Guo <gary@...yguo.net>, Björn Roy Baron
<bjorn3_gh@...tonmail.com>,
Benno Lossin <lossin@...nel.org>, Alice Ryhl <aliceryhl@...gle.com>,
Trevor Gross <tmgross@...ch.edu>, Danilo Krummrich <dakr@...nel.org>,
Matthew Wilcox <willy@...radead.org>, Andrew Morton
<akpm@...ux-foundation.org>
Cc: rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org, linux-mm@...ck.org, Daniel Almeida
<daniel.almeida@...labora.com>, Tamir Duberstein <tamird@...il.com>, Janne
Grunau <j@...nau.net>
Subject: Re: [PATCH v2 3/3] rust: xarray: add `insert` and `reserve`
"Tamir Duberstein" <tamird@...il.com> writes:
> Add `Guard::{insert,reserve}` and `Guard::{insert,reserve}_limit`, which
> are akin to `__xa_{alloc,insert}` in C.
>
> Note that unlike `xa_reserve` which only ensures that memory is
> allocated, the semantics of `Reservation` are stricter and require
> precise management of the reservation. Indices which have been reserved
> can still be overwritten with `Guard::store`, which allows for C-like
> semantics if desired.
>
> `__xa_cmpxchg_raw` is exported to facilitate the semantics described
> above.
>
> Tested-by: Janne Grunau <j@...nau.net>
> Reviewed-by: Janne Grunau <j@...nau.net>
> Signed-off-by: Tamir Duberstein <tamird@...il.com>
<cut>
> + /// Stores an element somewhere in the given range of indices.
> + ///
> + /// On success, takes ownership of `ptr`.
> + ///
> + /// On failure, ownership returns to the caller.
> + ///
> + /// # Safety
> + ///
> + /// `ptr` must be `NULL` or have come from a previous call to `T::into_foreign`.
> + unsafe fn alloc(
The naming of this method in C is confusing. Could we call it
insert_limit_raw on the Rust side?
Even though this is private, I think we should also document that the
effect of inserting NULL is to reserve the entry.
> + &mut self,
> + limit: impl ops::RangeBounds<u32>,
> + ptr: *mut T::PointedTo,
> + gfp: alloc::Flags,
> + ) -> Result<usize> {
> + // NB: `xa_limit::{max,min}` are inclusive.
> + let limit = bindings::xa_limit {
> + max: match limit.end_bound() {
> + ops::Bound::Included(&end) => end,
> + ops::Bound::Excluded(&end) => end - 1,
> + ops::Bound::Unbounded => u32::MAX,
> + },
> + min: match limit.start_bound() {
> + ops::Bound::Included(&start) => start,
> + ops::Bound::Excluded(&start) => start + 1,
> + ops::Bound::Unbounded => 0,
> + },
> + };
> +
> + let mut index = u32::MAX;
> +
> + // SAFETY:
> + // - `self.xa` is always valid by the type invariant.
> + // - `self.xa` was initialized with `XA_FLAGS_ALLOC` or `XA_FLAGS_ALLOC1`.
> + //
> + // INVARIANT: `ptr` is either `NULL` or came from `T::into_foreign`.
> + match unsafe {
> + bindings::__xa_alloc(
> + self.xa.xa.get(),
> + &mut index,
> + ptr.cast(),
> + limit,
> + gfp.as_raw(),
> + )
> + } {
> + 0 => Ok(to_usize(index)),
> + errno => Err(Error::from_errno(errno)),
> + }
> + }
> +
> + /// Allocates an entry somewhere in the array.
Should we rephrase this to match `alloc`?
Stores an entry somewhere in the given range of indices.
<cut>
> +impl<T: ForeignOwnable> Reservation<'_, T> {
> + /// Returns the index of the reservation.
> + pub fn index(&self) -> usize {
> + self.index
> + }
> +
> + /// Replaces the reserved entry with the given entry.
> + ///
> + /// # Safety
> + ///
> + /// `ptr` must be `NULL` or have come from a previous call to `T::into_foreign`.
We should document the effect of replacing with NULL.
Best regards,
Andreas Hindborg
Powered by blists - more mailing lists