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: <aAok4KhTHb86S26u@google.com>
Date: Thu, 24 Apr 2025 11:47:44 +0000
From: Alice Ryhl <aliceryhl@...gle.com>
To: Tamir Duberstein <tamird@...il.com>
Cc: Danilo Krummrich <dakr@...nel.org>, Matthew Maurer <mmaurer@...gle.com>, rust-for-linux@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 3/7] rust: alloc: add Vec::push_within_capacity

On Wed, Apr 23, 2025 at 11:38:28AM -0400, Tamir Duberstein wrote:
> On Tue, Apr 22, 2025 at 5:53 AM Alice Ryhl <aliceryhl@...gle.com> wrote:
> >
> > This introduces a new method called `push_within_capacity` for appending
> > to a vector without attempting to allocate if the capacity is full. Rust
> > Binder will use this in various places to safely push to a vector while
> > holding a spinlock.
> >
> > The implementation is moved to a push_within_capacity_unchecked method.
> > This is preferred over having push() call push_within_capacity()
> > followed by an unwrap_unchecked() for simpler unsafe.
> >
> > Signed-off-by: Alice Ryhl <aliceryhl@...gle.com>
> > +    /// Appends an element to the back of the [`Vec`] instance without reallocating.
> > +    ///
> > +    /// # Safety
> > +    ///
> > +    /// The length must be less than the capacity.
> > +    pub unsafe fn push_within_capacity_unchecked(&mut self, v: T) {
> 
> Did you intend for this to be pub? The commit message doesn't
> obviously indicate it.

Well, I don't think it hurts.

> >          let spare = self.spare_capacity_mut();
> >
> >          // SAFETY: The call to `reserve` was successful so the spare capacity is at least 1.
> 
> What call to reserve?

I have to update this comment, thanks.

> >          unsafe { spare.get_unchecked_mut(0) }.write(v);
> >
> >          // SAFETY: We just initialised the first spare entry, so it is safe to increase the length
> > -        // by 1. We also know that the new length is <= capacity because of the previous call to
> > -        // `reserve` above.
> > +        // by 1. We also know that the new length is <= capacity because the caller guarantees that
> > +        // the length is less than the capacity at the beginning of this function.
> >          unsafe { self.inc_len(1) };
> > -        Ok(())
> >      }

Alice

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ