Re: [PATCH v4 4/5] rust: types: ForeignOwnable: Add type Target

["Benno Lossin" <lossin@kernel.org>]

On Fri Jun 27, 2025 at 1:55 AM CEST, Boqun Feng wrote:
> On Thu, Jun 26, 2025, at 4:45 PM, Boqun Feng wrote:
>> On Thu, Jun 26, 2025, at 4:36 PM, Benno Lossin wrote:
>>> On Fri Jun 27, 2025 at 1:21 AM CEST, Boqun Feng wrote:
>>>> On Thu, Jun 26, 2025, at 4:17 PM, Benno Lossin wrote:
>>>>> On Thu Jun 26, 2025 at 10:20 PM CEST, Boqun Feng wrote:
>>>>>> On Thu, Jun 26, 2025 at 10:00:42PM +0200, Danilo Krummrich wrote:
>>>>>>> diff --git a/rust/kernel/types.rs b/rust/kernel/types.rs
>>>>>>> index 3958a5f44d56..74c787b352a9 100644
>>>>>>> --- a/rust/kernel/types.rs
>>>>>>> +++ b/rust/kernel/types.rs
>>>>>>> @@ -27,6 +27,9 @@
>>>>>>>  /// [`into_foreign`]: Self::into_foreign
>>>>>>>  /// [`PointedTo`]: Self::PointedTo
>>>>>>>  pub unsafe trait ForeignOwnable: Sized {
>>>>>>> +    /// The payload type of the foreign-owned value.
>>>>>>> +    type Target;
>>>>>>
>>>>>> I think `ForeignOwnable` also implies a `T` maybe get dropped via a
>>>>>> pointer from `into_foreign()`. Not sure it's worth mentioning though.
>>>>>
>>>>> What? How would that happen?
>>>>
>>>> The owner of the pointer can do from_foreign() and eventually drop
>>>> the ForeignOwnable, hence dropping T.
>>>
>>> I'm confused, you said `into_foreign` above. I don't think any sensible
>>> ForeignOwnable implementation will drop a T in any of its functions.
>>>
>>
>> A KBox<T> would drop T when it gets dropped, no?
>> A Arc<T> would drop T when it gets dropped if it’s the last refcount.
>>
>> I was trying to say “ForeignOwnable::drop() may implies Target::drop()”,
>> that’s what a “payload” means. Maybe that I used “T” instead of “Target”
>> in the original message caused confusion?

Ah now I understand what you are saying. Your mentioning of
`into_foreign` and `from_foreign` confused me. Yes a `ForeignOwnable`
may drop a `T`/`Target` in its own drop function. But I don't think we
need to document that.

> The point is whichever receives the pointer from a into_foreign()
> would owns the Target, because it can from_foreign() and
> drop the ForeignOwnable. So for example, if the pointer can
> be passed across threads, that means Target needs to be Send.

We should solve this in a different manner. Document the `Send` & `Sync`
requirements on `into_foreign`. So when you turn a `P: ForeignOwnable`
that is `!Send` into a raw pointer, you are not allowed to call
`from_foreign` on a different thread.

If `P: !Sync` then you're not allowed to call `borrow[_mut]` on the
pointer from two different threads (ie only the one that is currently
owning the value is allowed to call that).

---
Cheers,
Benno