All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Eliot Courtney" <ecourtney@nvidia.com>
To: "Alexandre Courbot" <acourbot@nvidia.com>,
	"Eliot Courtney" <ecourtney@nvidia.com>
Cc: "Danilo Krummrich" <dakr@kernel.org>,
	"Lorenzo Stoakes" <ljs@kernel.org>,
	"Vlastimil Babka" <vbabka@kernel.org>,
	"Liam R. Howlett" <liam@infradead.org>,
	"Uladzislau Rezki" <urezki@gmail.com>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Boqun Feng" <boqun@kernel.org>, "Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <lossin@kernel.org>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Daniel Almeida" <daniel.almeida@collabora.com>,
	"Tamir Duberstein" <tamird@kernel.org>,
	"Onur Özkan" <work@onurozkan.dev>,
	"David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>,
	"John Hubbard" <jhubbard@nvidia.com>,
	"Alistair Popple" <apopple@nvidia.com>,
	"Timur Tabi" <ttabi@nvidia.com>,
	rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
	nova-gpu@lists.linux.dev, dri-devel@lists.freedesktop.org,
	dri-devel <dri-devel-bounces@lists.freedesktop.org>
Subject: Re: [PATCH v3 1/8] rust: alloc: add Vec::try_push_init
Date: Tue, 13 Oct 2026 15:22:59 +0900	[thread overview]
Message-ID: <DM3HTEQWMPZ2.6IYTH17NNAA@nvidia.com> (raw)
In-Reply-To: <DLXISL19ZQBY.1E3J1G0HKGPZJ@nvidia.com>

On Tue Oct 6, 2026 at 2:52 PM JST, Alexandre Courbot wrote:
> On Mon Sep 28, 2026 at 5:42 PM JST, Eliot Courtney wrote:
>> Add `Vec::try_push_init` for fallible initializers (`impl Init<T, E>`)
>> and a new sum error type `PushInitError<I, E>` that it returns. If
>> allocation fails, it hands back the original initializer. A From impl
>
> nit: missing `` around "From".
>
>> for `Error` lets callers decay the `PushInitError<I, E>` to a regular
>> Error if they want.
>>
>> Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
>> ---
>>  rust/kernel/alloc/kvec.rs        | 55 ++++++++++++++++++++++++++++++++++++++--
>>  rust/kernel/alloc/kvec/errors.rs | 30 ++++++++++++++++++++++
>>  2 files changed, 83 insertions(+), 2 deletions(-)
>>
>> diff --git a/rust/kernel/alloc/kvec.rs b/rust/kernel/alloc/kvec.rs
>> index c7546b9da4fa..a2b72a7779d9 100644
>> --- a/rust/kernel/alloc/kvec.rs
>> +++ b/rust/kernel/alloc/kvec.rs
>> @@ -52,10 +52,18 @@
>>      }, //
>>  };
>>  
>> -use pin_init::Zeroable;
>> +use pin_init::{
>> +    Init,
>> +    Zeroable, //
>> +};
>>  
>>  mod errors;
>> -pub use self::errors::{InsertError, PushError, RemoveError};
>> +pub use self::errors::{
>> +    InsertError,
>> +    PushError,
>> +    PushInitError,
>> +    RemoveError, //
>> +};
>>  
>>  /// Create a [`KVec`] containing the arguments.
>>  ///
>> @@ -359,6 +367,49 @@ pub fn push(&mut self, v: T, flags: Flags) -> Result<(), AllocError> {
>>          Ok(())
>>      }
>>  
>> +    /// Appends an element to the back of the [`Vec`] instance by initializing it in place.
>> +    ///
>> +    /// Unlike [`Vec::push`], the initializer may be fallible. If the allocation fails, the
>> +    /// original initializer `init` is handed back in [`PushInitError::AllocError`]. If the
>> +    /// initializer itself fails, its error is returned in [`PushInitError::InitError`].
>> +    ///
>> +    /// # Examples
>> +    ///
>> +    /// ```
>> +    /// struct Element {
>> +    ///     buf: KVec<u8>,
>
> It becomes a tad confusing when the element of a `KVec` is itself a
> `KVec`... Can we just use primitive types inside `Element`?

SGTM, added the failure case in the example as well.

>
>> +    /// }
>> +    ///
>> +    /// impl Element {
>> +    ///     fn new() -> impl Init<Self, Error> {
>> +    ///         try_init!(Element {
>> +    ///             buf: KVec::with_capacity(16, GFP_KERNEL)?,
>> +    ///         }? Error)
>> +    ///     }
>> +    /// }
>> +    ///
>> +    /// let mut v: KVec<Element> = KVec::new();
>> +    /// v.try_push_init(Element::new(), GFP_KERNEL)?;
>> +    /// assert!(v[0].buf.is_empty());
>> +    /// # Ok::<(), Error>(())
>> +    /// ```
>> +    pub fn try_push_init<I, E>(&mut self, init: I, flags: Flags) -> Result<(), PushInitError<I, E>>
>> +    where
>> +        I: Init<T, E>,
>> +    {
>> +        if self.reserve(1, flags).is_err() {
>> +            return Err(PushInitError::AllocError(init));
>> +        }
>> +        // SAFETY: The call to `reserve` was successful, so there is at least one spare slot.
>> +        unsafe { init.__init(self.spare_capacity_mut().as_mut_ptr().cast::<T>()) }
>
> I guess it comes down to the same but I'd feel safer if we could
> explicitly index the first element using `get_unchecked_mut(0)`:
>
>     unsafe { init.__init(self.spare_capacity_mut().get_unchecked_mut(0).as_mut_ptr()) }
>
> (removing a cast is also nice I guess)

The file appears split on the convention here (get_unchecked_mut vs
get_mut_ptr + arithmetic + cast), but absolutely do not mind changing
this one here.

  reply	other threads:[~2026-10-13  6:23 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-28  8:42 [PATCH v3 0/8] gpu: nova-core: add NVKV codec Eliot Courtney
2026-09-28  8:42 ` [PATCH v3 1/8] rust: alloc: add Vec::try_push_init Eliot Courtney
2026-09-28  8:51   ` sashiko-bot
2026-10-06  5:52   ` Alexandre Courbot
2026-10-13  6:22     ` Eliot Courtney [this message]
2026-09-28  8:42 ` [PATCH v3 2/8] rust: alloc: add Vec::push_init Eliot Courtney
2026-09-28  8:52   ` sashiko-bot
2026-10-06  6:10   ` Alexandre Courbot
2026-09-28  8:42 ` [PATCH v3 3/8] rust: alloc: add ArrayVec Eliot Courtney
2026-09-28  8:51   ` sashiko-bot
2026-10-07  6:27   ` Alexandre Courbot
2026-10-13  9:13     ` Eliot Courtney
2026-09-28  8:42 ` [PATCH v3 4/8] gpu: nova-core: add NVKV encoder Eliot Courtney
2026-09-28  8:52   ` sashiko-bot
2026-10-07  3:43   ` Alexandre Courbot
2026-10-07  3:48     ` Alexandre Courbot
2026-10-07 11:33       ` John Hubbard
2026-10-07 11:56         ` Alexandre Courbot
2026-10-13  7:08           ` Eliot Courtney
2026-09-28  8:42 ` [PATCH v3 5/8] gpu: nova-core: add NVKV decoder Eliot Courtney
2026-09-28  8:52   ` sashiko-bot
2026-10-07  4:51   ` Alexandre Courbot
2026-10-13  8:26     ` Eliot Courtney
2026-09-28  8:42 ` [PATCH v3 6/8] gpu: nova-core: add NVKV typed encoding Eliot Courtney
2026-10-07  6:30   ` Alexandre Courbot
2026-09-28  8:42 ` [PATCH v3 7/8] gpu: nova-core: add NVKV typed decoding Eliot Courtney
2026-10-07  6:30   ` Alexandre Courbot
2026-10-07 12:05   ` Alexandre Courbot
2026-09-28  8:42 ` [PATCH v3 8/8] gpu: nova-core: add NVKV GSP_INIT schemas Eliot Courtney
2026-10-07 10:53   ` Alexandre Courbot

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=DM3HTEQWMPZ2.6IYTH17NNAA@nvidia.com \
    --to=ecourtney@nvidia.com \
    --cc=a.hindborg@kernel.org \
    --cc=acourbot@nvidia.com \
    --cc=airlied@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=apopple@nvidia.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun@kernel.org \
    --cc=dakr@kernel.org \
    --cc=daniel.almeida@collabora.com \
    --cc=dri-devel-bounces@lists.freedesktop.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gary@garyguo.net \
    --cc=jhubbard@nvidia.com \
    --cc=liam@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ljs@kernel.org \
    --cc=lossin@kernel.org \
    --cc=nova-gpu@lists.linux.dev \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=simona@ffwll.ch \
    --cc=tamird@kernel.org \
    --cc=tmgross@umich.edu \
    --cc=ttabi@nvidia.com \
    --cc=urezki@gmail.com \
    --cc=vbabka@kernel.org \
    --cc=work@onurozkan.dev \
    /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.