From: Boqun Feng <boqun.feng@gmail.com>
To: Alice Ryhl <aliceryhl@google.com>
Cc: Danilo Krummrich <dakr@kernel.org>,
Matthew Maurer <mmaurer@google.com>,
rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 6/7] rust: alloc: add Vec::remove
Date: Tue, 22 Apr 2025 15:24:28 -0700 [thread overview]
Message-ID: <6808171f.050a0220.393a1.5936@mx.google.com> (raw)
In-Reply-To: <20250422-vec-methods-v3-6-deff5eea568a@google.com>
On Tue, Apr 22, 2025 at 09:52:21AM +0000, Alice Ryhl wrote:
> This is needed by Rust Binder in the range allocator, and by upcoming
> GPU drivers during firmware initialization.
>
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
> ---
> rust/kernel/alloc/kvec.rs | 31 +++++++++++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
>
> diff --git a/rust/kernel/alloc/kvec.rs b/rust/kernel/alloc/kvec.rs
> index 2f894eac02212d15d902fe6702d6155f3128997c..2f28fda793e13841b59e83f34681e71ac815aff2 100644
> --- a/rust/kernel/alloc/kvec.rs
> +++ b/rust/kernel/alloc/kvec.rs
> @@ -386,6 +386,37 @@ pub fn pop(&mut self) -> Option<T> {
> Some(unsafe { removed.read() })
> }
>
> + /// Removes the element at the given index.
> + ///
> + /// # Examples
> + ///
> + /// ```
> + /// let mut v = kernel::kvec![1, 2, 3]?;
> + /// assert_eq!(v.remove(1), 2);
> + /// assert_eq!(v, [1, 3]);
> + /// # Ok::<(), Error>(())
> + /// ```
> + pub fn remove(&mut self, i: usize) -> T {
> + // INVARIANT: This breaks the invariants by invalidating the value at index `i`, but we
> + // restore the invariants below.
> + // SAFETY: Since `&self[i]` did not result in a panic, the value at index `i` is valid.
So a out-of-bound `i` would result into a panic? Then I think we need a
"# Panics" section?
> + let value = unsafe { ptr::read(&self[i]) };
> +
> + // SAFETY: Since the above access did not panic, the length is at least one.
> + unsafe { self.dec_len(1) };
> +
I think you need to move this line after the `ptr::copy()`, right?
Otherwise, you're using the *new* length to calculate how many elements
you are copying. (For example, in your above example, self.len is 2
after self.dec_len(), and the the following copy would be copy(p.add(1),
p, 2 - 1 - 1), which copies zero data, but it would be wrong.)
Regards,
Boqun
> + // SAFETY: We checked that `i` is in-bounds.
> + let p = unsafe { self.as_mut_ptr().add(i) };
> +
> + // INVARIANT: This restores the Vec invariants by moving the valid values into the region
> + // that is required to hold valid values.
> + // SAFETY: `p.add(1).add(self.len - i - 1)` is `i+1+len-i-1 == len` elements after the
> + // beginning of the vector, so this is in-bounds of the vector.
> + unsafe { ptr::copy(p.add(1), p, self.len - i - 1) };
> +
> + value
> + }
> +
> /// Creates a new [`Vec`] instance with at least the given capacity.
> ///
> /// # Examples
>
> --
> 2.49.0.805.g082f7c87e0-goog
>
>
next prev parent reply other threads:[~2025-04-22 22:24 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-22 9:52 [PATCH v3 0/7] Additional methods for Vec Alice Ryhl
2025-04-22 9:52 ` [PATCH v3 1/7] rust: alloc: add Vec::clear Alice Ryhl
2025-04-22 9:52 ` [PATCH v3 2/7] rust: alloc: add Vec::pop Alice Ryhl
2025-04-23 15:42 ` Tamir Duberstein
2025-04-24 11:48 ` Alice Ryhl
2025-04-24 13:48 ` Tamir Duberstein
2025-04-22 9:52 ` [PATCH v3 3/7] rust: alloc: add Vec::push_within_capacity Alice Ryhl
2025-04-22 21:29 ` Boqun Feng
2025-04-23 8:55 ` Alice Ryhl
2025-04-23 15:59 ` Boqun Feng
2025-04-23 15:38 ` Tamir Duberstein
2025-04-24 11:47 ` Alice Ryhl
2025-04-22 9:52 ` [PATCH v3 4/7] rust: alloc: add Vec::drain_all Alice Ryhl
2025-04-22 9:52 ` [PATCH v3 5/7] rust: alloc: add Vec::retain Alice Ryhl
2025-04-23 12:14 ` Danilo Krummrich
2025-04-24 11:46 ` Alice Ryhl
2025-04-24 13:49 ` Tamir Duberstein
2025-04-25 9:30 ` Alice Ryhl
2025-04-22 9:52 ` [PATCH v3 6/7] rust: alloc: add Vec::remove Alice Ryhl
2025-04-22 22:24 ` Boqun Feng [this message]
2025-04-23 8:33 ` Alice Ryhl
2025-04-22 9:52 ` [PATCH v3 7/7] rust: alloc: add Vec::insert_within_capacity Alice Ryhl
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=6808171f.050a0220.393a1.5936@mx.google.com \
--to=boqun.feng@gmail.com \
--cc=aliceryhl@google.com \
--cc=dakr@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mmaurer@google.com \
--cc=rust-for-linux@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.