From: Danilo Krummrich <dakr@kernel.org>
To: Heghedus Razvan <heghedus.razvan@protonmail.com>
Cc: ojeda@kernel.org, alex.gaynor@gmail.com, wedsonaf@gmail.com,
boqun.feng@gmail.com, gary@garyguo.net, bjorn3_gh@protonmail.com,
benno.lossin@proton.me, a.hindborg@samsung.com,
aliceryhl@google.com, akpm@linux-foundation.org,
daniel.almeida@collabora.com, faith.ekstrand@collabora.com,
boris.brezillon@collabora.com, lina@asahilina.net,
mcanal@igalia.com, zhiw@nvidia.com, acurrid@nvidia.com,
cjia@nvidia.com, jhubbard@nvidia.com, airlied@redhat.com,
ajanulgu@redhat.com, lyude@redhat.com,
linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH v2 16/23] rust: alloc: implement `collect` for `IntoIter`
Date: Wed, 24 Jul 2024 22:32:41 +0200 [thread overview]
Message-ID: <ZqFk6bWrTUCDh3m6@pollux> (raw)
In-Reply-To: <D2XUESJWJNIY.3HP9IDB0NKFYI@protonmail.com>
On Wed, Jul 24, 2024 at 02:35:46PM +0000, Heghedus Razvan wrote:
> On Tue Jul 23, 2024 at 9:10 PM EEST, Danilo Krummrich wrote:
> > Currently, we can't implement `FromIterator`. There are a couple of
> > issues with this trait in the kernel, namely:
> >
> > - Rust's specialization feature is unstable. This prevents us to
> > optimze for the special case where `I::IntoIter` equals `Vec`'s
> > `IntoIter` type.
> > - We also can't use `I::IntoIter`'s type ID either to work around this,
> > since `FromIterator` doesn't require this type to be `'static`.
> > - `FromIterator::from_iter` does return `Self` instead of
> > `Result<Self, AllocError>`, hence we can't properly handle allocation
> > failures.
> > - Neither `Iterator::collect` nor `FromIterator::from_iter` can handle
> > additional allocation flags.
> Well that's a shame, so I guess collecting a Filter or Map is not possible.
Not with the Rust's `FromIterator` trait, unfortunately. However, once we have
other collectable data structures in place, we can come up with a kernel
compatible version of the `FromIterator` trait and implement against it.
>
> >
> > Instead, provide `IntoIter::collect`, such that we can at least convert
> > `IntoIter` into a `Vec` again.
> >
> > Signed-off-by: Danilo Krummrich <dakr@kernel.org>
> > ---
> > rust/kernel/alloc/kvec.rs | 80 ++++++++++++++++++++++++++++++++++++++-
> > 1 file changed, 79 insertions(+), 1 deletion(-)
> >
> > diff --git a/rust/kernel/alloc/kvec.rs b/rust/kernel/alloc/kvec.rs
> > index fbfb755b252d..5c317931e14c 100644
> > --- a/rust/kernel/alloc/kvec.rs
> > +++ b/rust/kernel/alloc/kvec.rs
> > @@ -2,7 +2,7 @@
> >
> > //! Implementation of [`Vec`].
> >
> > -use super::{AllocError, Allocator, Flags};
> > +use super::{flags::*, AllocError, Allocator, Flags};
> > use crate::types::Unique;
> > use core::{
> > fmt,
> > @@ -633,6 +633,84 @@ impl<T, A> IntoIter<T, A>
> > fn as_raw_mut_slice(&mut self) -> *mut [T] {
> > ptr::slice_from_raw_parts_mut(self.ptr, self.len)
> > }
> > +
> > + fn into_raw_parts(self) -> (*mut T, NonNull<T>, usize, usize) {
> > + let me = ManuallyDrop::new(self);
> > + let ptr = me.ptr;
> > + let buf = me.buf;
> > + let len = me.len;
> > + let cap = me.cap;
> > + (ptr, buf, len, cap)
> > + }
> > +
> > + /// Same as `Iterator::collect` but specialized for `Vec`'s `IntoIter`.
> > + ///
> > + /// Currently, we can't implement `FromIterator`. There are a couple of issues with this trait
> > + /// in the kernel, namely:
> > + ///
> > + /// - Rust's specialization feature is unstable. This prevents us to optimze for the special
> > + /// case where `I::IntoIter` equals `Vec`'s `IntoIter` type.
> > + /// - We also can't use `I::IntoIter`'s type ID either to work around this, since `FromIterator`
> > + /// doesn't require this type to be `'static`.
> > + /// - `FromIterator::from_iter` does return `Self` instead of `Result<Self, AllocError>`, hence
> > + /// we can't properly handle allocation failures.
> > + /// - Neither `Iterator::collect` nor `FromIterator::from_iter` can handle additional allocation
> > + /// flags.
> > + ///
> > + /// Instead, provide `IntoIter::collect`, such that we can at least convert a `IntoIter` into a
> > + /// `Vec` again.
> > + ///
> > + /// Note that `IntoIter::collect` doesn't require `Flags`, since it re-uses the existing backing
> > + /// buffer. However, this backing buffer may be shrunk to the actual count of elements.
> > + ///
> > + /// # Examples
> > + ///
> > + /// ```
> > + /// let v = kernel::kvec![1, 2, 3]?;
> > + /// let mut it = v.into_iter();
> > + ///
> > + /// assert_eq!(it.next(), Some(1));
> > + ///
> > + /// let v = it.collect();
> > + /// assert_eq!(v, [2, 3]);
> > + ///
> > + /// # Ok::<(), Error>(())
> > + /// ```
> > + pub fn collect(self) -> Vec<T, A> {
> > + let (mut ptr, buf, len, mut cap) = self.into_raw_parts();
> > + let has_advanced = ptr != buf.as_ptr();
> > +
> > + if has_advanced {
> > + // SAFETY: Copy the contents we have advanced to at the beginning of the buffer.
> > + // `ptr` is guaranteed to be between `buf` and `buf.add(cap)` and `ptr.add(len)` is
> > + // guaranteed to be smaller than `buf.add(cap)`.
> > + unsafe { ptr::copy(ptr, buf.as_ptr(), len) };
> > + ptr = buf.as_ptr();
> > + }
> > +
> > + // This can never fail, `len` is guaranteed to be smaller than `cap`.
> > + let layout = core::alloc::Layout::array::<T>(len).unwrap();
> > +
> > + // SAFETY: `buf` points to the start of the backing buffer and `len` is guaranteed to be
> > + // smaller than `cap`. Depending on `alloc` this operation may shrink the buffer or leaves
> > + // it as it is.
> > + ptr = match unsafe { A::realloc(Some(buf.cast()), layout, GFP_KERNEL) } {
> Here you use `GFP_KERNEL` flag directly. Shouldn't this be an argument of `collect` function?
Even though we only ever ask the allocator to shrink the buffer (or keep it as
it is), it should be, good catch!
>
> > + // If we fail to shrink, which likely can't even happen, continue with the existing
> > + // buffer.
> > + Err(_) => ptr,
> > + Ok(ptr) => {
> > + cap = len;
> > + ptr.as_ptr().cast()
> > + }
> > + };
> > +
> > + // SAFETY: If the iterator has been advanced, the advanced elements have been copied to
> > + // the beginning of the buffer and `len` has been adjusted accordingly. `ptr` is guaranteed
> > + // to point to the start of the backing buffer. `cap` is either the original capacity or,
> > + // after shrinking the buffer, equal to `len`. `alloc` is guaranteed to be unchanged since
> > + // `into_iter` has been called on the original `Vec`.
> > + unsafe { Vec::from_raw_parts(ptr, len, cap) }
> > + }
> > }
> >
> > impl<T, A> Iterator for IntoIter<T, A>
> > --
> > 2.45.2
>
>
next prev parent reply other threads:[~2024-07-24 20:32 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-23 18:09 [PATCH v2 00/23] Generic `Allocator` support for Rust Danilo Krummrich
2024-07-23 18:09 ` [PATCH v2 01/23] rust: alloc: add `Allocator` trait Danilo Krummrich
2024-07-23 18:09 ` [PATCH v2 02/23] rust: alloc: separate `aligned_size` from `krealloc_aligned` Danilo Krummrich
2024-07-23 18:09 ` [PATCH v2 03/23] rust: alloc: rename `KernelAllocator` to `Kmalloc` Danilo Krummrich
2024-07-23 18:09 ` [PATCH v2 04/23] rust: alloc: implement `Allocator` for `Kmalloc` Danilo Krummrich
2024-07-23 18:09 ` [PATCH v2 05/23] rust: alloc: add module `allocator_test` Danilo Krummrich
2024-07-23 18:09 ` [PATCH v2 06/23] rust: alloc: implement `Vmalloc` allocator Danilo Krummrich
2024-07-23 18:09 ` [PATCH v2 07/23] rust: alloc: implement `KVmalloc` allocator Danilo Krummrich
2024-07-23 18:09 ` [PATCH v2 08/23] rust: types: implement `Unique<T>` Danilo Krummrich
2024-07-23 18:09 ` [PATCH v2 09/23] rust: alloc: implement kernel `Box` Danilo Krummrich
2024-07-23 18:09 ` [PATCH v2 10/23] rust: treewide: switch to our kernel `Box` type Danilo Krummrich
2024-07-23 18:10 ` [PATCH v2 11/23] rust: alloc: remove `BoxExt` extension Danilo Krummrich
2024-07-23 18:10 ` [PATCH v2 12/23] rust: alloc: add `Box` to prelude Danilo Krummrich
2024-07-23 18:10 ` [PATCH v2 13/23] rust: alloc: import kernel `Box` type in types.rs Danilo Krummrich
2024-07-23 18:10 ` [PATCH v2 14/23] rust: alloc: implement kernel `Vec` type Danilo Krummrich
2024-07-23 18:10 ` [PATCH v2 15/23] rust: alloc: implement `IntoIterator` for `Vec` Danilo Krummrich
2024-07-23 18:10 ` [PATCH v2 16/23] rust: alloc: implement `collect` for `IntoIter` Danilo Krummrich
2024-07-24 14:35 ` Heghedus Razvan
2024-07-24 20:32 ` Danilo Krummrich [this message]
2024-07-23 18:10 ` [PATCH v2 17/23] rust: treewide: switch to the kernel `Vec` type Danilo Krummrich
2024-07-23 18:10 ` [PATCH v2 18/23] rust: alloc: remove `VecExt` extension Danilo Krummrich
2024-07-23 18:10 ` [PATCH v2 19/23] rust: alloc: add `Vec` to prelude Danilo Krummrich
2024-07-23 18:10 ` [PATCH v2 20/23] rust: alloc: remove `GlobalAlloc` and `krealloc_aligned` Danilo Krummrich
2024-07-23 18:10 ` [PATCH v2 21/23] rust: error: use `core::alloc::LayoutError` Danilo Krummrich
2024-07-23 18:10 ` [PATCH v2 22/23] rust: str: test: replace `alloc::format` Danilo Krummrich
2024-07-23 18:10 ` [PATCH v2 23/23] kbuild: rust: remove the `alloc` crate Danilo Krummrich
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=ZqFk6bWrTUCDh3m6@pollux \
--to=dakr@kernel.org \
--cc=a.hindborg@samsung.com \
--cc=acurrid@nvidia.com \
--cc=airlied@redhat.com \
--cc=ajanulgu@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=boris.brezillon@collabora.com \
--cc=cjia@nvidia.com \
--cc=daniel.almeida@collabora.com \
--cc=faith.ekstrand@collabora.com \
--cc=gary@garyguo.net \
--cc=heghedus.razvan@protonmail.com \
--cc=jhubbard@nvidia.com \
--cc=lina@asahilina.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lyude@redhat.com \
--cc=mcanal@igalia.com \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=wedsonaf@gmail.com \
--cc=zhiw@nvidia.com \
/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.