All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Hindborg <nmi@metaspace.dk>
To: Alice Ryhl <aliceryhl@google.com>
Cc: rust-for-linux@vger.kernel.org, "Miguel Ojeda" <ojeda@kernel.org>,
	"Wedson Almeida Filho" <wedsonaf@gmail.com>,
	"Tejun Heo" <tj@kernel.org>,
	"Lai Jiangshan" <jiangshanlai@gmail.com>,
	"Alex Gaynor" <alex.gaynor@gmail.com>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	"Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <benno.lossin@proton.me>,
	linux-kernel@vger.kernel.org, patches@lists.linux.dev
Subject: Re: [PATCH v1 3/7] rust: sync: add `Arc::{from_raw, into_raw}`
Date: Wed, 24 May 2023 12:20:36 +0200	[thread overview]
Message-ID: <87edn6do1b.fsf@metaspace.dk> (raw)
In-Reply-To: <20230517203119.3160435-4-aliceryhl@google.com>


Alice Ryhl <aliceryhl@google.com> writes:

> From: Wedson Almeida Filho <walmeida@microsoft.com>
>
> These methods can be used to turn an `Arc` into a raw pointer and back,
> in a way that preserves the metadata for fat pointers.
>
> This is done using the unstable ptr_metadata feature [1]. However, it
> could also be done using the unstable pointer_byte_offsets feature [2],
> which is likely to have a shorter path to stabilization than
> ptr_metadata.
>
> Link: https://github.com/rust-lang/rust/issues/81513 [1]
> Link: https://github.com/rust-lang/rust/issues/96283 [2]
> Signed-off-by: Wedson Almeida Filho <walmeida@microsoft.com>
> Co-developed-by: Alice Ryhl <aliceryhl@google.com>
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
> ---
>  rust/kernel/lib.rs      |  1 +
>  rust/kernel/sync/arc.rs | 44 +++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 45 insertions(+)
>
> diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
> index cdf9fe999328..82854c86e65d 100644
> --- a/rust/kernel/lib.rs
> +++ b/rust/kernel/lib.rs
> @@ -22,6 +22,7 @@
>  #![feature(generic_associated_types)]
>  #![feature(new_uninit)]
>  #![feature(pin_macro)]
> +#![feature(ptr_metadata)]
>  #![feature(receiver_trait)]
>  #![feature(unsize)]
>  
> diff --git a/rust/kernel/sync/arc.rs b/rust/kernel/sync/arc.rs
> index e6d206242465..7c55a9178dfb 100644
> --- a/rust/kernel/sync/arc.rs
> +++ b/rust/kernel/sync/arc.rs
> @@ -210,6 +210,50 @@ impl<T: ?Sized> Arc<T> {
>          }
>      }
>  
> +    /// Convert the [`Arc`] into a raw pointer.
> +    ///
> +    /// The raw pointer has ownership of the refcount that this Arc object owned.
> +    pub fn into_raw(self) -> *const T {
> +        let ptr = self.ptr.as_ptr();
> +        core::mem::forget(self);
> +        // SAFETY: The pointer is valid.
> +        unsafe { core::ptr::addr_of!((*ptr).data) }
> +    }
> +
> +    /// Recreates an [`Arc`] instance previously deconstructed via [`Arc::into_raw`].
> +    ///
> +    /// This code relies on the `repr(C)` layout of structs as described in
> +    /// <https://doc.rust-lang.org/reference/type-layout.html#reprc-structs>.
> +    ///
> +    /// # Safety
> +    ///
> +    /// `ptr` must have been returned by a previous call to [`Arc::into_raw`]. Additionally, it
> +    /// can only be called once for each previous call to [`Arc::into_raw`].
> +    pub unsafe fn from_raw(ptr: *const T) -> Self {
> +        // SAFETY: The safety requirement ensures that the pointer is valid.
> +        let val_align = core::mem::align_of_val(unsafe { &*ptr });
> +        let refcount_size = core::mem::size_of::<Opaque<bindings::refcount_t>>();
> +
> +        // Use the `repr(C)` algorithm to compute the offset of `data` in `ArcInner`.
> +        //
> +        // Pseudo-code for the `#[repr(C)]` algorithm can be found here:
> +        // <https://doc.rust-lang.org/reference/type-layout.html#reprc-structs>
> +        let mut val_offset = refcount_size;
> +        let val_misalign = val_offset % val_align;
> +        if val_misalign > 0 {
> +            val_offset += val_align - val_misalign;
> +        }
> +
> +        // This preserves the metadata in the pointer, if any.
> +        let metadata = core::ptr::metadata(ptr as *const ArcInner<T>);

I can't follow this. How does this work? `ptr` was for field
`inner.data: T`, but we are casting to `ArcInner<T>`.

> +        let ptr = (ptr as *mut u8).wrapping_sub(val_offset) as *mut ();
> +        let ptr = core::ptr::from_raw_parts_mut(ptr, metadata);

Metadata was obtained from a pointer pointing to `inner.data`, we then
move it back to beginning of `ArcInner<T>` and then reconstruct the
potentially fat pointer with metadata from the pointer to `T`? How can
this be right?

BR Andreas

> +
> +        // 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)) }
> +    }
> +
>      /// Returns an [`ArcBorrow`] from the given [`Arc`].
>      ///
>      /// This is useful when the argument of a function call is an [`ArcBorrow`] (e.g., in a method


  parent reply	other threads:[~2023-05-24 10:25 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-17 20:31 [PATCH v1 0/7] Bindings for the workqueue Alice Ryhl
2023-05-17 20:31 ` [PATCH v1 1/7] rust: workqueue: add low-level workqueue bindings Alice Ryhl
2023-05-18 14:51   ` Martin Rodriguez Reboredo
2023-05-19  9:40     ` Alice Ryhl
2023-05-19 12:04       ` Martin Rodriguez Reboredo
2023-05-23 10:03         ` Alice Ryhl
2023-05-30  8:26   ` Andreas Hindborg
2023-05-17 20:31 ` [PATCH v1 2/7] rust: add offset_of! macro Alice Ryhl
2023-05-18 14:51   ` Martin Rodriguez Reboredo
2023-05-23 15:48   ` Gary Guo
2023-05-24 12:26     ` Alice Ryhl
2023-05-30  8:40     ` Andreas Hindborg
2023-05-17 20:31 ` [PATCH v1 3/7] rust: sync: add `Arc::{from_raw, into_raw}` Alice Ryhl
2023-05-18 14:51   ` Martin Rodriguez Reboredo
2023-05-23 15:43   ` Gary Guo
2023-05-24 11:19     ` Alice Ryhl
2023-05-24 10:20   ` Andreas Hindborg [this message]
2023-05-24 11:11     ` Alice Ryhl
2023-05-25  7:45       ` Andreas Hindborg
2023-05-25 16:32         ` Gary Guo
2023-05-30  7:23           ` Andreas Hindborg
2023-05-17 20:31 ` [PATCH v1 4/7] rust: workqueue: define built-in queues Alice Ryhl
2023-05-18 14:52   ` Martin Rodriguez Reboredo
2023-05-25 11:40   ` Andreas Hindborg
2023-05-31 14:02     ` Alice Ryhl
2023-06-02 10:23       ` Andreas Hindborg (Samsung)
2023-05-17 20:31 ` [PATCH v1 5/7] rust: workqueue: add helper for defining work_struct fields Alice Ryhl
2023-05-18 23:18   ` Martin Rodriguez Reboredo
2023-05-24 14:50   ` Benno Lossin
2023-05-30  8:44   ` Andreas Hindborg
2023-05-31  9:00     ` Alice Ryhl
2023-05-31 10:18       ` Andreas Hindborg
2023-05-17 20:31 ` [PATCH v1 6/7] rust: workqueue: add safe API to workqueue Alice Ryhl
2023-05-19  0:17   ` Martin Rodriguez Reboredo
2023-05-23 11:07     ` Alice Ryhl
2023-05-30  7:19       ` Andreas Hindborg
2023-05-30 13:23         ` Martin Rodriguez Reboredo
2023-05-30 14:13       ` Miguel Ojeda
2023-05-24 14:51   ` Benno Lossin
2023-05-31  9:07     ` Alice Ryhl
2023-05-30  8:51   ` Andreas Hindborg
2023-05-31 14:07     ` Alice Ryhl
2023-05-17 20:31 ` [PATCH v1 7/7] rust: workqueue: add `try_spawn` helper method Alice Ryhl
2023-05-18  6:15   ` kernel test robot
2023-05-19  0:22   ` Martin Rodriguez Reboredo
2023-05-22  9:39   ` kernel test robot
2023-05-24 14:52   ` Benno Lossin
2023-05-31 14:03     ` Alice Ryhl
2023-05-17 21:48 ` [PATCH v1 0/7] Bindings for the workqueue Tejun Heo
2023-05-17 22:22   ` Alice Ryhl
2023-05-23 14:08     ` Andreas Hindborg
2023-05-23 14:14 ` Andreas Hindborg
2023-05-24 12:33   ` 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=87edn6do1b.fsf@metaspace.dk \
    --to=nmi@metaspace.dk \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=benno.lossin@proton.me \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=gary@garyguo.net \
    --cc=jiangshanlai@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ojeda@kernel.org \
    --cc=patches@lists.linux.dev \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tj@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.