linux-kernel - Re: [PATCH v3] rust: alloc: implement `extend` for `Vec`

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aAollRd0-SnirG2a@google.com>
Date: Thu, 24 Apr 2025 11:50:45 +0000
From: Alice Ryhl <aliceryhl@...gle.com>
To: Boqun Feng <boqun.feng@...il.com>
Cc: Alexandre Courbot <acourbot@...dia.com>, Danilo Krummrich <dakr@...nel.org>, 
	Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>, Gary Guo <gary@...yguo.net>, 
	"Björn Roy Baron" <bjorn3_gh@...tonmail.com>, Benno Lossin <benno.lossin@...ton.me>, 
	Andreas Hindborg <a.hindborg@...nel.org>, Trevor Gross <tmgross@...ch.edu>, 
	Joel Fernandes <joelagnelf@...dia.com>, John Hubbard <jhubbard@...dia.com>, 
	rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] rust: alloc: implement `extend` for `Vec`

On Wed, Apr 23, 2025 at 09:03:40AM -0700, Boqun Feng wrote:
> On Wed, Apr 23, 2025 at 06:40:07PM +0900, Alexandre Courbot wrote:
> > On Wed Apr 23, 2025 at 5:51 PM JST, Alice Ryhl wrote:
> > > On Wed, Apr 23, 2025 at 10:02:58AM +0900, Alexandre Courbot wrote:
> > > The stdlib alloc crate relies on specialization to speed up methods
> > > related to iterators. We can't use specialization, so losing these
> > > optimizations is simply a cost of not using the upstream alloc library
> > > that we have to accept.
> > 
> > Yeah I was surprised to see
> > 
> >   impl<T, I, A: Allocator> SpecExtend<T, I> for Vec<T, A>
> >   where
> >       I: Iterator<Item = T>
> > 
> > and
> > 
> >   impl<T, I, A: Allocator> SpecExtend<T, I> for Vec<T, A>
> >   where
> >       I: TrustedLen<Item = T>
> > 
> > in the standard library, which clearly looks like an overlap. Didn't
> > know it was relying on a non-standard feature.
> > 
> > That's going to limit what we can do in the kernel, but nonetheless if
> > we can support only the cases that can be optimized I think we would
> > have our bases covered.
> 
> I think if it's a critical path and we really need the performance, we
> can use a non-standard/non-stable feature or get that stabilized.

We should not expect that we can just stabilize even a minimum form of
specialization. It's a very non-trivial feature.

Alice