mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Benno Lossin <benno.lossin@proton.me>
To: Alice Ryhl <aliceryhl@google.com>,
	Miguel Ojeda <ojeda@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: "Alex Gaynor" <alex.gaynor@gmail.com>,
	"Wedson Almeida Filho" <wedsonaf@gmail.com>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	"Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Andreas Hindborg" <a.hindborg@samsung.com>,
	"Marco Elver" <elver@google.com>,
	"Kees Cook" <keescook@chromium.org>, "Coly Li" <colyli@suse.de>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Pierre Gondois" <pierre.gondois@arm.com>,
	"Ingo Molnar" <mingo@kernel.org>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Wei Yang" <richard.weiyang@gmail.com>,
	"Matthew Wilcox" <willy@infradead.org>,
	linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org
Subject: Re: [PATCH 1/9] rust: list: add ListArc
Date: Wed, 03 Apr 2024 15:51:42 +0000	[thread overview]
Message-ID: <2f25f21e-fad8-48bb-aa2b-d61bf8909a41@proton.me> (raw)
In-Reply-To: <20240402-linked-list-v1-1-b1c59ba7ae3b@google.com>

On 02.04.24 14:16, Alice Ryhl wrote:
> +impl<T: ListArcSafe<ID>, const ID: u64> ListArc<T, ID> {
> +    /// Constructs a new reference counted instance of `T`.
> +    pub fn try_new(contents: T) -> Result<Self, AllocError> {
> +        Ok(Self::from_unique(UniqueArc::try_new(contents)?))
> +    }
> +
> +    /// Use the given initializer to in-place initialize a `T`.
> +    ///
> +    /// If `T: !Unpin` it will not be able to move afterwards.
> +    pub fn pin_init<E>(init: impl PinInit<T, E>) -> error::Result<Self>
> +    where
> +        Error: From<E>,
> +    {
> +        Ok(Self::from_pin_unique(UniqueArc::pin_init(init)?))
> +    }

pin-init has a general trait for this: InPlaceInit. I don't know if the
other functions that it provides would help you.

> +}
> +
> +impl<T, const ID: u64> ListArc<T, ID>
> +where
> +    T: ListArcSafe<ID> + ?Sized,
> +{
> +    /// Convert a [`UniqueArc`] into a [`ListArc`].
> +    pub fn from_unique(mut unique: UniqueArc<T>) -> Self {
> +        // SAFETY: We have a `UniqueArc`, so there is no `ListArc`.
> +        unsafe { T::on_create_list_arc_from_unique(&mut unique) };
> +        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) }
> +    }
> +
> +    /// Convert a pinned [`UniqueArc`] into a [`ListArc`].
> +    pub fn from_pin_unique(unique: Pin<UniqueArc<T>>) -> Self {
> +        // SAFETY: We continue to treat this pointer as pinned after this call, since `ListArc`
> +        // implicitly pins its value.

This is not sufficient, since you also rely on `Self::from_unique` to
handle the parameter as if it were pinned, which it does not. Since it
calls `T::on_create_list_arc_from_unique` which just gets a `&mut self`
as a parameter and it could move stuff out.

> +        Self::from_unique(unsafe { Pin::into_inner_unchecked(unique) })
> +    }
> +
> +    /// Like [`from_unique`], but creates two `ListArcs`.
> +    ///
> +    /// The two ids must be different.
> +    ///
> +    /// [`from_unique`]: ListArc::from_unique
> +    pub fn pair_from_unique<const ID2: u64>(mut unique: UniqueArc<T>) -> (Self, ListArc<T, ID2>)
> +    where
> +        T: ListArcSafe<ID2>,
> +    {
> +        assert_ne!(ID, ID2);

Can this be a `build_assert!`?

> +
> +        // SAFETY: We have a `UniqueArc`, so we can call this method.

I liked the comment from above better:

     // SAFETY: We have a `UniqueArc`, so there is no `ListArc`.

Maybe use the variation "so there are no `ListArc`s for any ID.".

> +        unsafe { <T as ListArcSafe<ID>>::on_create_list_arc_from_unique(&mut unique) };
> +        // SAFETY: We have a `UniqueArc`, so we can call this method. The two ids are not equal.
> +        unsafe { <T as ListArcSafe<ID2>>::on_create_list_arc_from_unique(&mut unique) };
> +
> +        let arc1 = Arc::from(unique);
> +        let arc2 = Arc::clone(&arc1);
> +
> +        // SAFETY: We just called `on_create_list_arc_from_unique` on an arc without a `ListArc`,
> +        // so we can create a `ListArc`.

I would mention the two different IDs again.

> +        unsafe {
> +            (
> +                Self::transmute_from_arc(arc1),
> +                ListArc::transmute_from_arc(arc2),
> +            )
> +        }
> +    }
> +
> +    /// Like [`pair_from_unique`], but uses a pinned arc.
> +    ///
> +    /// The two ids must be different.
> +    ///
> +    /// [`pair_from_unique`]: ListArc::pair_from_unique
> +    pub fn pair_from_pin_unique<const ID2: u64>(
> +        unique: Pin<UniqueArc<T>>,
> +    ) -> (Self, ListArc<T, ID2>)
> +    where
> +        T: ListArcSafe<ID2>,
> +    {
> +        // SAFETY: We continue to treat this pointer as pinned after this call, since `ListArc`
> +        // implicitly pins its value.
> +        Self::pair_from_unique(unsafe { Pin::into_inner_unchecked(unique) })
> +    }
> +
> +    /// Transmutes an [`Arc`] into a `ListArc` without updating the tracking inside `T`.
> +    ///
> +    /// # Safety
> +    ///
> +    /// * The value must not already have a `ListArc` reference.
> +    /// * The tracking inside `T` must think that there is a `ListArc` reference.
> +    #[inline]
> +    unsafe fn transmute_from_arc(me: Arc<T>) -> Self {
> +        // INVARIANT: By the safety requirements, the invariants on `ListArc` are satisfied.
> +        // SAFETY: ListArc is repr(transparent).
> +        unsafe { core::mem::transmute(me) }

Why do you need a transmute here? Can't you just construct the struct?

     Self { arc: me }

-- 
Cheers,
Benno

> +    }
> +


  reply	other threads:[~2024-04-03 15:51 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-02 12:16 [PATCH 0/9] Add Rust linked list for reference counted values Alice Ryhl
2024-04-02 12:16 ` [PATCH 1/9] rust: list: add ListArc Alice Ryhl
2024-04-03 15:51   ` Benno Lossin [this message]
2024-04-04 14:00     ` Alice Ryhl
2024-05-03 14:36       ` Alice Ryhl
2024-05-04 15:50         ` Benno Lossin
2024-04-03 17:18   ` Kane York
2024-04-02 12:16 ` [PATCH 2/9] rust: list: add tracking for ListArc Alice Ryhl
2024-04-03 15:52   ` Benno Lossin
2024-04-04 14:14     ` Alice Ryhl
2024-04-04 14:41       ` Benno Lossin
2024-04-02 12:17 ` [PATCH 3/9] rust: list: add struct with prev/next pointers Alice Ryhl
2024-04-03 15:57   ` Benno Lossin
2024-04-04 14:03     ` Alice Ryhl
2024-04-04 14:05       ` Benno Lossin
2024-04-05  9:47   ` Benno Lossin
2024-04-08  7:57     ` Alice Ryhl
2024-04-02 12:17 ` [PATCH 4/9] rust: list: add macro for implementing ListItem Alice Ryhl
2024-04-03 10:42   ` Benno Lossin
2024-04-02 12:17 ` [PATCH 5/9] rust: list: add List Alice Ryhl
2024-04-04 14:03   ` Benno Lossin
2024-04-04 14:12     ` Alice Ryhl
2024-04-04 14:51       ` Benno Lossin
2024-04-08  8:04         ` Alice Ryhl
2024-04-08  8:51           ` Benno Lossin
2024-04-02 12:17 ` [PATCH 6/9] rust: list: add iterators Alice Ryhl
2024-04-04 14:36   ` Benno Lossin
2024-04-04 14:41     ` Alice Ryhl
2024-04-04 14:52       ` Benno Lossin
2024-04-08  8:00         ` Alice Ryhl
2024-04-02 12:17 ` [PATCH 7/9] rust: list: add cursor Alice Ryhl
2024-04-03 12:19   ` Benno Lossin
2024-04-03 12:49     ` Alice Ryhl
2024-04-04 13:28       ` Benno Lossin
2024-04-04 13:40         ` Alice Ryhl
2024-04-02 12:17 ` [PATCH 8/9] rust: list: support heterogeneous lists Alice Ryhl
2024-04-04 15:35   ` Benno Lossin
2024-04-08  7:59     ` Alice Ryhl
2024-04-02 12:17 ` [PATCH 9/9] rust: list: add ListArcField Alice Ryhl
2024-04-04 15:47   ` Benno Lossin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2f25f21e-fad8-48bb-aa2b-d61bf8909a41@proton.me \
    --to=benno.lossin@proton.me \
    --cc=a.hindborg@samsung.com \
    --cc=akpm@linux-foundation.org \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=colyli@suse.de \
    --cc=elver@google.com \
    --cc=gary@garyguo.net \
    --cc=keescook@chromium.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=ojeda@kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pierre.gondois@arm.com \
    --cc=richard.weiyang@gmail.com \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=wedsonaf@gmail.com \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®