From: Boqun Feng <boqun.feng@gmail.com>
To: Alice Ryhl <aliceryhl@google.com>
Cc: "Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Wedson Almeida Filho" <wedsonaf@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <benno.lossin@proton.me>,
"Andreas Hindborg" <a.hindborg@samsung.com>,
rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] rust: sync: add `ArcBorrow::from_raw`
Date: Mon, 19 Feb 2024 21:36:05 -0800 [thread overview]
Message-ID: <ZdQ6RRYtvazV7WPR@boqun-archlinux> (raw)
In-Reply-To: <20240219-arc-for-list-v1-1-d98cd92c760b@google.com>
On Mon, Feb 19, 2024 at 02:54:11PM +0000, Alice Ryhl wrote:
> Allows access to a value in an `Arc` that is currently held as a raw
> pointer due to use of `Arc::into_raw`, without destroying or otherwise
> consuming that raw pointer.
>
> This is a dependency of the linked list that Rust Binder uses. The
> linked list uses this method when iterating over the linked list.
>
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
> ---
> rust/kernel/sync/arc.rs | 72 ++++++++++++++++++++++++++++++++++++-------------
> 1 file changed, 54 insertions(+), 18 deletions(-)
>
> diff --git a/rust/kernel/sync/arc.rs b/rust/kernel/sync/arc.rs
> index 7d4c4bf58388..a5314df409e7 100644
> --- a/rust/kernel/sync/arc.rs
> +++ b/rust/kernel/sync/arc.rs
> @@ -232,27 +232,13 @@ pub fn into_raw(self) -> *const T {
> /// `ptr` must have been returned by a previous call to [`Arc::into_raw`]. Additionally, it
> /// must not be called more than once for each previous call to [`Arc::into_raw`].
> pub unsafe fn from_raw(ptr: *const T) -> Self {
> - let refcount_layout = Layout::new::<bindings::refcount_t>();
> - // SAFETY: The caller guarantees that the pointer is valid.
> - let val_layout = Layout::for_value(unsafe { &*ptr });
> - // SAFETY: We're computing the layout of a real struct that existed when compiling this
> - // binary, so its layout is not so large that it can trigger arithmetic overflow.
> - let val_offset = unsafe { refcount_layout.extend(val_layout).unwrap_unchecked().1 };
> -
> - // Pointer casts leave the metadata unchanged. This is okay because the metadata of `T` and
> - // `ArcInner<T>` is the same since `ArcInner` is a struct with `T` as its last field.
> - //
> - // This is documented at:
> - // <https://doc.rust-lang.org/std/ptr/trait.Pointee.html>.
> - let ptr = ptr as *const ArcInner<T>;
> -
> - // SAFETY: The pointer is in-bounds of an allocation both before and after offsetting the
> - // pointer, since it originates from a previous call to `Arc::into_raw` and is still valid.
> - let ptr = unsafe { ptr.byte_sub(val_offset) };
> + // SAFETY: The pointer returned by `into_raw` points at the `data` field of an
> + // `ArcInner<T>`, as promised by the caller.
> + let ptr = unsafe { raw_to_inner_ptr(ptr) };
>
> // SAFETY: By the safety requirements we know that `ptr` came from `Arc::into_raw`, so the
> // reference count held then will be owned by the new `Arc` object.
> - unsafe { Self::from_inner(NonNull::new_unchecked(ptr.cast_mut())) }
> + unsafe { Self::from_inner(ptr) }
> }
>
> /// Returns an [`ArcBorrow`] from the given [`Arc`].
> @@ -273,6 +259,35 @@ pub fn ptr_eq(this: &Self, other: &Self) -> bool {
> }
> }
>
> +/// Converts a pointer to the contents of an [`Arc`] into a pointer to the [`ArcInner`].
> +///
> +/// # Safety
> +///
> +/// The provided pointer must point the `data` field of an `ArcInner<T>` value.
> +unsafe fn raw_to_inner_ptr<T: ?Sized>(ptr: *const T) -> NonNull<ArcInner<T>> {
Nit: put this into an `impl<T:?Sized> ArcInner<T>` block maybe?
> + let refcount_layout = Layout::new::<bindings::refcount_t>();
> + // SAFETY: The caller guarantees that the pointer is valid.
> + let val_layout = Layout::for_value(unsafe { &*ptr });
> + // SAFETY: We're computing the layout of a real struct that existed when compiling this
> + // binary, so its layout is not so large that it can trigger arithmetic overflow.
> + let val_offset = unsafe { refcount_layout.extend(val_layout).unwrap_unchecked().1 };
> +
> + // Pointer casts leave the metadata unchanged. This is okay because the metadata of `T` and
> + // `ArcInner<T>` is the same since `ArcInner` is a struct with `T` as its last field.
> + //
> + // This is documented at:
> + // <https://doc.rust-lang.org/std/ptr/trait.Pointee.html>.
> + let ptr = ptr as *const ArcInner<T>;
> +
> + // SAFETY: The pointer is in-bounds of an allocation both before and after offsetting the
> + // pointer, since it originates from a previous call to `Arc::into_raw` and is still valid.
"since it originate from a previous call to `Arc::into_raw`" is the
safety requirement of `Arc::from_raw`, since the safety requirement of
`raw_to_inner_ptr` is different, so I think we should say "since the
function safety requirement guarantees `ptr` points to `data` field,
which is exactly `val_offset` away from the beginning of `ArcInner<T>`".
Thoughts?
BTW, in fat pointer cases, by "must point the `data` field of an
`ArcInner<T>` value", it means both the address and the metadata should
be the same as the original object in `ArcInner<T>`, right? In other
words, the following code should not be safe, i.e. the
raw_to_inner_ptr() safety requirement is not satisfied.
let x: Arc<[u8]> // assume x.len() == 4
let y = &(x[0..1]) as *const [u8] // y has the same address of
// the `data` field of `x`.
let inner = unsafe { raw_to_inner_ptr(y) };
// ^^^ the safety requirement is not satisfied???
This may not be important since the users of `raw_to_inner_ptr` all have
stronger safey guarantees ("`ptr` must come from `Arc::into_raw()`"),
and `raw_to_inner_ptr` is not a pub function, but I just wonder whether
we need to improve the current safety requirements, or "point" means
both address and metadata for fat pointers?
Regards,
Boqun
> + let ptr = unsafe { ptr.byte_sub(val_offset) };
> +
> + // SAFETY: The pointer can't be null since you can't have an `ArcInner<T>` value at the null
> + // address.
> + unsafe { NonNull::new_unchecked(ptr.cast_mut()) }
> +}
> +
> impl<T: 'static> ForeignOwnable for Arc<T> {
> type Borrowed<'a> = ArcBorrow<'a, T>;
>
> @@ -453,6 +468,27 @@ unsafe fn new(inner: NonNull<ArcInner<T>>) -> Self {
> _p: PhantomData,
> }
> }
> +
> + /// Creates an [`ArcBorrow`] to an [`Arc`] that has previously been deconstructed with
> + /// [`Arc::into_raw`].
> + ///
> + /// # Safety
> + ///
> + /// * The provided pointer must originate from a call to [`Arc::into_raw`].
> + /// * For the duration of the lifetime annotated on this `ArcBorrow`, the reference count must
> + /// not hit zero.
> + /// * For the duration of the lifetime annotated on this `ArcBorrow`, there must not be a
> + /// [`UniqueArc`] reference to this value.
> + pub unsafe fn from_raw(ptr: *const T) -> Self {
> + // SAFETY: The pointer returned by `into_raw` points at the `data` field of an
> + // `ArcInner<T>`.
> + let ptr = unsafe { raw_to_inner_ptr(ptr) };
> +
> + // SAFETY: The caller promises that the value remains valid since the reference count must
> + // not hit zero, and no mutable reference will be created since that would involve a
> + // `UniqueArc`.
> + unsafe { Self::new(ptr) }
> + }
> }
>
> impl<T: ?Sized> From<ArcBorrow<'_, T>> for Arc<T> {
>
> --
> 2.44.0.rc0.258.g7320e95886-goog
>
next prev parent reply other threads:[~2024-02-20 5:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-19 14:54 [PATCH 0/2] Arc methods for linked list Alice Ryhl
2024-02-19 14:54 ` [PATCH 1/2] rust: sync: add `ArcBorrow::from_raw` Alice Ryhl
2024-02-20 5:36 ` Boqun Feng [this message]
2024-02-20 9:25 ` Alice Ryhl
2024-02-19 14:54 ` [PATCH 2/2] rust: sync: add `Arc::into_unique_or_drop` Alice Ryhl
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=ZdQ6RRYtvazV7WPR@boqun-archlinux \
--to=boqun.feng@gmail.com \
--cc=a.hindborg@samsung.com \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=gary@garyguo.net \
--cc=linux-kernel@vger.kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=wedsonaf@gmail.com \
/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;
as well as URLs for NNTP newsgroup(s).