linux-kernel - Re: [PATCH v2 1/9] rust: list: add ListArc

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: <3d04db54-8561-4c09-82c0-6ebcfb3e9ceb@proton.me>
Date: Mon, 27 May 2024 09:25:16 +0000
From: Benno Lossin <benno.lossin@...ton.me>
To: Alice Ryhl <aliceryhl@...gle.com>, Miguel Ojeda <ojeda@...nel.org>, Andrew Morton <akpm@...ux-foundation.org>
Cc: Alex Gaynor <alex.gaynor@...il.com>, Wedson Almeida Filho <wedsonaf@...il.com>, Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>, Björn Roy Baron <bjorn3_gh@...tonmail.com>, Andreas Hindborg <a.hindborg@...sung.com>, Marco Elver <elver@...gle.com>, Kees Cook <keescook@...omium.org>, Coly Li <colyli@...e.de>, Paolo Abeni <pabeni@...hat.com>, Pierre Gondois <pierre.gondois@....com>, Ingo Molnar <mingo@...nel.org>, Jakub Kicinski <kuba@...nel.org>, Wei Yang <richard.weiyang@...il.com>, Matthew Wilcox <willy@...radead.org>, linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org
Subject: Re: [PATCH v2 1/9] rust: list: add ListArc

On 06.05.24 11:53, Alice Ryhl wrote:
> +impl<T, const ID: u64> ListArc<T, ID>
> +where
> +    T: ListArcSafe<ID> + ?Sized,
> +{
> +    /// Convert a [`UniqueArc`] into a [`ListArc`].
> +    #[inline]
> +    pub fn from_unique(unique: UniqueArc<T>) -> Self {
> +        Self::from_pin_unique(Pin::from(unique))
> +    }
> +
> +    /// Convert a pinned [`UniqueArc`] into a [`ListArc`].
> +    #[inline]
> +    pub fn from_pin_unique(mut unique: Pin<UniqueArc<T>>) -> Self {
> +        // SAFETY: We have a `UniqueArc`, so there is no `ListArc`.
> +        unsafe { T::on_create_list_arc_from_unique(unique.as_mut()) };
> +        let arc = Arc::from(unique);
> +        // SAFETY: We just called `on_create_list_arc_from_unique` on an arc without a `ListArc`,
> +        // so we can create a `ListArc`.
> +        unsafe { Self::transmute_from_arc(arc) }
> +    }

I think these two functions would make sense as `From` impls.

> +
> +    /// Like [`from_unique`], but creates two `ListArcs`.
> +    ///
> +    /// The two ids must be different.
> +    ///
> +    /// [`from_unique`]: ListArc::from_unique
> +    #[inline]
> +    pub fn pair_from_unique<const ID2: u64>(unique: UniqueArc<T>) -> (Self, ListArc<T, ID2>)
> +    where
> +        T: ListArcSafe<ID2>,
> +    {
> +        Self::pair_from_pin_unique(Pin::from(unique))
> +    }

[...]

> +    /// Returns a reference to an [`Arc`] from the given [`ListArc`].
> +    ///
> +    /// This is useful when the argument of a function call is an [`&Arc`] (e.g., in a method
> +    /// receiver), but we have a [`ListArc`] instead.
> +    ///
> +    /// [`&Arc`]: Arc
> +    #[inline]
> +    pub fn as_arc(&self) -> &Arc<T> {
> +        &self.arc
> +    }

Should this be an `AsRef` impl instead?

---
Cheers,
Benno

> +
> +    /// Returns an [`ArcBorrow`] from the given [`ListArc`].
> +    ///
> +    /// This is useful when the argument of a function call is an [`ArcBorrow`] (e.g., in a method
> +    /// receiver), but we have an [`Arc`] instead. Getting an [`ArcBorrow`] is free when optimised.
> +    #[inline]
> +    pub fn as_arc_borrow(&self) -> ArcBorrow<'_, T> {
> +        self.arc.as_arc_borrow()
> +    }

[...]