From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-40131.protonmail.ch (mail-40131.protonmail.ch [185.70.40.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 33CE017D8BB for ; Tue, 30 Jul 2024 18:06:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.70.40.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722362790; cv=none; b=uuq+Z5CDYQl9oNtxqTTMdN8V8btawEjA/YzghJuj8ly6UlurvIIYm4oU+FBtGSU4HpzCynaVilajxwHFJHpGQQYKyLIfQUsnxWIzbC34csSK4BAhfgXY/qzVwOkgHjpaLZglXxwA5r+5ZuP2ZOSeIs8hSftm0fmzPxtrYg0fKTQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722362790; c=relaxed/simple; bh=IfON4uBqEKOf2xcMASP8BDONDtL4WQ0cJawE3iEfHRI=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=p6Qesk+2W0dRoy7coeFz6fz1MMXLY0TeBkDB8SE4MouDqCPb5nNppqEuXSBcEMhjzWuBSXfRKH2Xht7t+ywPYuFt0Y0V93oqhwXP4Y8vCAQxK0zpD56lY33c6O7+IqWcYqQ8Dn6mq+b07hLq+7gQtGGIBtgzZ7HF8XuTS06GLJ8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=proton.me; spf=pass smtp.mailfrom=proton.me; dkim=pass (2048-bit key) header.d=proton.me header.i=@proton.me header.b=mlCg+bct; arc=none smtp.client-ip=185.70.40.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=proton.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=proton.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=proton.me header.i=@proton.me header.b="mlCg+bct" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1722362786; x=1722621986; bh=mP8pPR7V7GOEbvgnQ3Hkpe5+bVYgYFu8/oCcIpUDYGY=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=mlCg+bctF5dxmG58f3kM8tbwGVBPxm9/xZlgY1XUEkCPSvWCKa6gjZLRI0b9MgHhx dsBEMt7RtV1zCo+ks8HO/eQRN+YEct4mRYtxAgKsMMRfBCI11OJmtNYYnlyhZNm0Gh ZTJuXEgFzojCNJk7rxTEXpCppQV/zyouyo6NZEsi7/bHrZDkiZT3ZWBhqSwdTdhDHB mFyVBw/kP0Cud63CH4kE8ZS0MCXb3wbVmGO7km0kvGEjoXpXDV+nxn/YpXPtqcHlj2 JBp2FfuvS8GTjQ47+gNU1h70yWIs8PnAHp7c26kpxwaoHZoGNMK6ijMBxGC2sb0xN3 ktVuyabmio5eg== Date: Tue, 30 Jul 2024 18:06:20 +0000 To: Alice Ryhl From: Benno Lossin Cc: Miguel Ojeda , Alex Gaynor , Wedson Almeida Filho , Boqun Feng , Gary Guo , =?utf-8?Q?Bj=C3=B6rn_Roy_Baron?= , Andreas Hindborg , rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] rust: implement ForeignOwnable for Pin> Message-ID: <6cfa426b-4ffe-41bc-9de5-ba7c7c70d610@proton.me> In-Reply-To: References: <20240730-foreign-ownable-pin-box-v1-1-b1d70cdae541@google.com> <5c49f604-34c1-414f-bf9a-92837c6e07b3@proton.me> Feedback-ID: 71780778:user:proton X-Pm-Message-ID: 65c413bde632019c722f6d70d12b0831868560f6 Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 30.07.24 19:50, Alice Ryhl wrote: > On Tue, Jul 30, 2024 at 7:14=E2=80=AFPM Benno Lossin 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 ForeignOwnable for Pin> { >>> + type Borrowed<'a> =3D 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. >=20 > 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 >> 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? >=20 > 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