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] [day] [month] [year] [list]

Message-ID: <aAo-XiP-OHA_4itj@Mac.home>
Date: Thu, 24 Apr 2025 06:36:30 -0700
From: Boqun Feng <boqun.feng@...il.com>
To: Alice Ryhl <aliceryhl@...gle.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 Thu, Apr 24, 2025 at 11:50:45AM +0000, Alice Ryhl wrote:
> 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.
> 

Maybe I should have worded differently, the point is we should not limit
ourselves to "a cost of not using the upstream alloc library that we
have to accept", so yeah specialization is a non-trivial feature, but
what we can do is presenting the problem to the Rust community and
seeking for a solution for our problem. Similar to `CoercePointee`,
unsize coerce in general is a feature that is hard to be stabilized, but
for a specific problem that we care, we found a solution.

The Linux kernel needs should be one of the sources that push new
features in Rust language, don't you agree?

Regards,
Boqun

> Alice