rust-for-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] rust: implement ForeignOwnable for Pin<Box<T>>
@ 2024-07-30 13:06 Alice Ryhl
  2024-07-30 17:14 ` Benno Lossin
  2024-08-18 21:31 ` Miguel Ojeda
  0 siblings, 2 replies; 5+ messages in thread
From: Alice Ryhl @ 2024-07-30 13:06 UTC (permalink / raw)
  To: Miguel Ojeda
  Cc: Alex Gaynor, Wedson Almeida Filho, Boqun Feng, Gary Guo,
	Björn Roy Baron, Benno Lossin, Andreas Hindborg,
	rust-for-linux, linux-kernel, Alice Ryhl

We already implement ForeignOwnable for Box<T>, but it may be useful to
store pinned data in a ForeignOwnable container. This patch makes that
possible.

This will be used together with upcoming miscdev abstractions, which
Binder will use when binderfs is disabled.

Signed-off-by: Alice Ryhl <aliceryhl@google.com>
---
 rust/kernel/types.rs | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/rust/kernel/types.rs b/rust/kernel/types.rs
index bd189d646adb..132ca1113083 100644
--- a/rust/kernel/types.rs
+++ b/rust/kernel/types.rs
@@ -9,6 +9,7 @@
     marker::{PhantomData, PhantomPinned},
     mem::MaybeUninit,
     ops::{Deref, DerefMut},
+    pin::Pin,
     ptr::NonNull,
 };
 
@@ -89,6 +90,32 @@ unsafe fn from_foreign(ptr: *const core::ffi::c_void) -> Self {
     }
 }
 
+impl<T: 'static> ForeignOwnable for Pin<Box<T>> {
+    type Borrowed<'a> = Pin<&'a T>;
+
+    fn into_foreign(self) -> *const core::ffi::c_void {
+        // SAFETY: We are still treating the box as pinned.
+        Box::into_raw(unsafe { Pin::into_inner_unchecked(self) }) as _
+    }
+
+    unsafe fn borrow<'a>(ptr: *const core::ffi::c_void) -> Pin<&'a T> {
+        // SAFETY: The safety requirements for this function ensure that the object is still alive,
+        // so it is safe to dereference the raw pointer.
+        // The safety requirements of `from_foreign` also ensure that the object remains alive for
+        // the lifetime of the returned value.
+        let r = unsafe { &*ptr.cast() };
+
+        // SAFETY: This pointer originates from a `Pin<Box<T>>`.
+        unsafe { Pin::new_unchecked(r) }
+    }
+
+    unsafe fn from_foreign(ptr: *const core::ffi::c_void) -> Self {
+        // SAFETY: The safety requirements of this function ensure that `ptr` comes from a previous
+        // call to `Self::into_foreign`.
+        unsafe { Pin::new_unchecked(Box::from_raw(ptr as _)) }
+    }
+}
+
 impl ForeignOwnable for () {
     type Borrowed<'a> = ();
 

---
base-commit: 8400291e289ee6b2bf9779ff1c83a291501f017b
change-id: 20240730-foreign-ownable-pin-box-515cf790977c

Best regards,
-- 
Alice Ryhl <aliceryhl@google.com>


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH] rust: implement ForeignOwnable for Pin<Box<T>>
  2024-07-30 13:06 [PATCH] rust: implement ForeignOwnable for Pin<Box<T>> Alice Ryhl
@ 2024-07-30 17:14 ` Benno Lossin
  2024-07-30 17:50   ` Alice Ryhl
  2024-08-18 21:31 ` Miguel Ojeda
  1 sibling, 1 reply; 5+ messages in thread
From: Benno Lossin @ 2024-07-30 17:14 UTC (permalink / raw)
  To: Alice Ryhl, Miguel Ojeda
  Cc: Alex Gaynor, Wedson Almeida Filho, Boqun Feng, Gary Guo,
	Björn Roy Baron, Andreas Hindborg, rust-for-linux,
	linux-kernel

On 30.07.24 15:06, Alice Ryhl wrote:
> @@ -89,6 +90,32 @@ unsafe fn from_foreign(ptr: *const core::ffi::c_void) -> Self {
>      }
>  }
> 
> +impl<T: 'static> ForeignOwnable for Pin<Box<T>> {
> +    type Borrowed<'a> = Pin<&'a T>;
> +
> +    fn into_foreign(self) -> *const core::ffi::c_void {
> +        // SAFETY: We are still treating the box as pinned.

I don't think that we have the guarantee that the pointee at the pointer
that is returned by `into_foreign` is not moved.
AFAIU `ForeignOwnable` is used to store these pointers in C structures
and never to actually access the value behind the returned pointer. So
we could add the requirement to `into_foreign` (thus making it `unsafe`)
that the pointer should not be dereferenced/used aside from `borrow` and
`from_foreign`. Otherwise I don't see how the call below can be OK.
What do you think?

---
Cheers,
Benno

> +        Box::into_raw(unsafe { Pin::into_inner_unchecked(self) }) as _
> +    }


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] rust: implement ForeignOwnable for Pin<Box<T>>
  2024-07-30 17:14 ` Benno Lossin
@ 2024-07-30 17:50   ` Alice Ryhl
  2024-07-30 18:06     ` Benno Lossin
  0 siblings, 1 reply; 5+ messages in thread
From: Alice Ryhl @ 2024-07-30 17:50 UTC (permalink / raw)
  To: Benno Lossin
  Cc: Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho, Boqun Feng,
	Gary Guo, Björn Roy Baron, Andreas Hindborg, rust-for-linux,
	linux-kernel

On Tue, Jul 30, 2024 at 7:14 PM Benno Lossin <benno.lossin@proton.me> wrote:
>
> On 30.07.24 15:06, Alice Ryhl wrote:
> > @@ -89,6 +90,32 @@ unsafe fn from_foreign(ptr: *const core::ffi::c_void) -> Self {
> >      }
> >  }
> >
> > +impl<T: 'static> ForeignOwnable for Pin<Box<T>> {
> > +    type Borrowed<'a> = Pin<&'a T>;
> > +
> > +    fn into_foreign(self) -> *const core::ffi::c_void {
> > +        // SAFETY: We are still treating the box as pinned.
>
> I don't think that we have the guarantee that the pointee at the pointer
> that is returned by `into_foreign` is not moved.

That doesn't seem like the kind of thing we need a guarantee for.
Rather, unless we give anyone a guarantee that dereferencing it is
okay, it seems reasonable to assume that it won't be dereferenced.
Right now, it's just an opaque pointer, so C really shouldn't be
touching it. We already implement the trait for Arc which is also
pinned and also doesn't even point at a value of type T.

> AFAIU `ForeignOwnable` is used to store these pointers in C structures
> and never to actually access the value behind the returned pointer. So
> we could add the requirement to `into_foreign` (thus making it `unsafe`)
> that the pointer should not be dereferenced/used aside from `borrow` and
> `from_foreign`. Otherwise I don't see how the call below can be OK.
> What do you think?

Dereferencing the void pointer is unsafe in itself, so I don't see why
`into_foreign` has to be unsafe too.

Alice

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] rust: implement ForeignOwnable for Pin<Box<T>>
  2024-07-30 17:50   ` Alice Ryhl
@ 2024-07-30 18:06     ` Benno Lossin
  0 siblings, 0 replies; 5+ messages in thread
From: Benno Lossin @ 2024-07-30 18:06 UTC (permalink / raw)
  To: Alice Ryhl
  Cc: Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho, Boqun Feng,
	Gary Guo, Björn Roy Baron, Andreas Hindborg, rust-for-linux,
	linux-kernel

On 30.07.24 19:50, Alice Ryhl wrote:
> On Tue, Jul 30, 2024 at 7:14 PM Benno Lossin <benno.lossin@proton.me> wrote:
>>
>> On 30.07.24 15:06, Alice Ryhl wrote:
>>> @@ -89,6 +90,32 @@ unsafe fn from_foreign(ptr: *const core::ffi::c_void) -> Self {
>>>      }
>>>  }
>>>
>>> +impl<T: 'static> ForeignOwnable for Pin<Box<T>> {
>>> +    type Borrowed<'a> = Pin<&'a T>;
>>> +
>>> +    fn into_foreign(self) -> *const core::ffi::c_void {
>>> +        // SAFETY: We are still treating the box as pinned.
>>
>> I don't think that we have the guarantee that the pointee at the pointer
>> that is returned by `into_foreign` is not moved.
> 
> That doesn't seem like the kind of thing we need a guarantee for.
> Rather, unless we give anyone a guarantee that dereferencing it is
> okay, it seems reasonable to assume that it won't be dereferenced.
> Right now, it's just an opaque pointer, so C really shouldn't be
> touching it. We already implement the trait for Arc which is also
> pinned and also doesn't even point at a value of type T.

Hmm, I don't have any rational concerns with this, but it doesn't _feel_
right...

When I replace the return type by `OpaquePtr(*const core::ffi::c_void)`
that is `repr(transparent)` I don't feel like this is a problem any
more.
So I guess your argument is fine.

I think it shouldn't hurt to add this to the docs, will send a patch for
that. Anyways,

Reviewed-by: Benno Lossin <benno.lossin@proton.me>

>> AFAIU `ForeignOwnable` is used to store these pointers in C structures
>> and never to actually access the value behind the returned pointer. So
>> we could add the requirement to `into_foreign` (thus making it `unsafe`)
>> that the pointer should not be dereferenced/used aside from `borrow` and
>> `from_foreign`. Otherwise I don't see how the call below can be OK.
>> What do you think?
> 
> Dereferencing the void pointer is unsafe in itself, so I don't see why
> `into_foreign` has to be unsafe too.

Oh yes, you are right.

---
Cheers,
Benno


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] rust: implement ForeignOwnable for Pin<Box<T>>
  2024-07-30 13:06 [PATCH] rust: implement ForeignOwnable for Pin<Box<T>> Alice Ryhl
  2024-07-30 17:14 ` Benno Lossin
@ 2024-08-18 21:31 ` Miguel Ojeda
  1 sibling, 0 replies; 5+ messages in thread
From: Miguel Ojeda @ 2024-08-18 21:31 UTC (permalink / raw)
  To: Alice Ryhl
  Cc: Miguel Ojeda, Alex Gaynor, Wedson Almeida Filho, Boqun Feng,
	Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
	rust-for-linux, linux-kernel

On Tue, Jul 30, 2024 at 3:06 PM Alice Ryhl <aliceryhl@google.com> wrote:
>
> We already implement ForeignOwnable for Box<T>, but it may be useful to
> store pinned data in a ForeignOwnable container. This patch makes that
> possible.
>
> This will be used together with upcoming miscdev abstractions, which
> Binder will use when binderfs is disabled.
>
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>

Applied to `rust-next` -- thanks everyone!

Cheers,
Miguel

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2024-08-18 21:32 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-07-30 13:06 [PATCH] rust: implement ForeignOwnable for Pin<Box<T>> Alice Ryhl
2024-07-30 17:14 ` Benno Lossin
2024-07-30 17:50   ` Alice Ryhl
2024-07-30 18:06     ` Benno Lossin
2024-08-18 21:31 ` Miguel Ojeda

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).