From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 15C71371897; Wed, 19 Aug 2026 10:49:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787136560; cv=none; b=XGIlh07VKKO1T8DCHGHnbUfKE1bOyvPudoUytmqrEevvVQ18YkvFqtuN5NcKPGKzMXg+xmdRpmWeTUwb0b7WJ8VYmgok24z+yBdPJtBeNj4huAAVLeaiYx8aJE0zi9gyc4dacsQxBp8UvvXf39Zaxje2TGPvCG3nph3U/MLlhEA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787136560; c=relaxed/simple; bh=UBl+DybGTRkEpIBN7KCtLf04Inn14jPlhQS7sy1Ts0M=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:To:From:Subject: References:In-Reply-To; b=vDph2WSpKzM/jsIc8ev31IwRTva36csPBqAyKvxCAGWU1W6Njs31CmzYCX2Mlq8Zgw2kpxHbD7+ACgD/L8RP0DU6RvZwwlXItwTs8R39shmsiHXbpBfNWhi+EkHY/ivnisIX++267NkqLuYLWFeJl34UB6Cl47yYsnz+8oOYwDA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=m/rN8o/F; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="m/rN8o/F" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EDE3D1F000E9; Wed, 19 Aug 2026 10:49:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1787136558; bh=zQEfCl7xKtaCC78VIxZhzOSbdkzpLQaDYkBz+b+0oOI=; h=Date:Cc:To:From:Subject:References:In-Reply-To; b=m/rN8o/F9l7+jStt/C2McbVvIk/y0RPYIV/dxNC82qKtn7BUlie0m4HFlHeNJs7/x eHUoJ/yk4p3P08IhjMOZ9LhQLVitMytRBtXHrG0rmLPm4R8HblsKsEM7zLlv/JTxoy e0o5itCDVjt/xUSnKlDUsi6cLjYplRfZr7AZ6DqoE9L3O+k7cuLfWBwwbtRuXAo//N YsGbcrd4gz7WFtBwmw6G5+XWqkqBpne9kjsISHb47g6NKkRXzxWxsMhnSkuPx4k6Hd 4aYF/NPA5Ay6HBSGmFIup9UAt8L7rxy3g+rgtCdOmdWNvoJDfK3sUKgVn6aEbf/okY fnYVzjtyKJpMQ== Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 19 Aug 2026 12:49:12 +0200 Message-Id: Cc: "Gary Guo" , "Lorenzo Stoakes" , "Vlastimil Babka" , "Liam R. Howlett" , "Uladzislau Rezki" , "Miguel Ojeda" , "Boqun Feng" , =?utf-8?q?Bj=C3=B6rn_Roy_Baron?= , "Benno Lossin" , "Andreas Hindborg" , "Alice Ryhl" , "Trevor Gross" , "Daniel Almeida" , "Tamir Duberstein" , "Alexandre Courbot" , =?utf-8?q?Onur_=C3=96zkan?= , "David Airlie" , "Simona Vetter" , "John Hubbard" , "Alistair Popple" , "Timur Tabi" , , , , , "dri-devel" To: "Eliot Courtney" From: "Danilo Krummrich" Subject: Re: [PATCH 1/6] rust: alloc: add Vec::push_init References: <20260817-b4-nvkv-v1-0-b84db5e84b67@nvidia.com> <20260817-b4-nvkv-v1-1-b84db5e84b67@nvidia.com> In-Reply-To: On Wed Aug 19, 2026 at 9:43 AM CEST, Eliot Courtney wrote: > There's also some locations in other code that could use a VecView direct= ly > instead of taking a &mut Vec etc. Having a Vec-like thing that's guarante= ed not > to allocate also sounds potentially useful to me w.r.t. safety for contex= ts > where you can't allocate/sleep. Allocation in atomic context is still possible as long as we avoid memory reclaim, e.g. with GFP_ATOMIC. However, this should generally be avoided, p= lus there are also cases in non-atomic context where we can't have memory recla= im, such as the DMA fence signaling critical section. So, I think this can a be= a useful API. > If you think this approach is ok I can send it as a separate series. Code= gen > appears fine practically speaking AFAICT. I think this is orthogonal from what you need in this series; also remember= that we need a user with real need for an API before we can introduce it. It might have a use-case in DRM Jobqueue, where it could be used to handle pre-allocation for ring buffer slots of jobs before entering the DMA fence signaling critical section. However, I'm not convinced that Vec or a VecDeq= ue like type is the best solution for DRM Jobqueue in the first place. > pub type Zero =3D (); > pub type Succ =3D (N,); > pub type One =3D Succ; > pub type Two =3D Succ; That can produce annoying error messages, but without const generic expr it= is what it is. > // Infallible (except for Init) push. `Zero` spare VecView has the fallib= le version. > impl<'a, T, N: Count> VecView<'a, T, Succ> { > pub fn push(self, init: impl Init) -> Result, E> { We still want push() taking impl Init and try_push() taking impl Init, so we get rid of the Result for impl Init. > // Fallible but not allocating ops (can run out of space). > impl<'a, T> VecView<'a, T> { > pub fn push, E>(&mut self, init: I) -> Result<(), PushI= nitError> { > if *self.len =3D=3D self.cap { > return Err(PushInitError::Full(init)); > } > > unsafe { init.__init(self.buf.as_ptr().add(*self.len)) }.map_err(= PushInitError::Init)?; > *self.len +=3D 1; > > Ok(()) > } > > // Bodies as in the current KVec implementations. We'd still need forwarding functions on Vec, so we don't force users to go through view(). > pub fn pop(&mut self) -> Option { ... } > pub fn insert(&mut self, index: usize, element: T) -> Result<(), Inse= rtError> { ... } > pub fn remove(&mut self, i: usize) -> Result { ... } > pub fn truncate(&mut self, len: usize) { ... } > pub fn retain(&mut self, f: impl FnMut(&mut T) -> bool) { ... } > pub fn drain_all(self) -> DrainAll<'a, T> { ... } > pub fn len(&self) -> usize { ... } > pub fn as_slice(&self) -> &[T] { ... } > pub fn as_mut_slice(&mut self) -> &mut [T] { ... } > pub fn spare_capacity(&self) -> usize { ... } > pub fn spare_capacity_mut(&mut self) -> &mut [MaybeUninit] { ... } > pub unsafe fn commit(&mut self, additional: usize) { ... } > }