From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22]) (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 38B1224EA9D for ; Wed, 5 Mar 2025 14:56:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.70.43.22 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741186586; cv=none; b=dSTsJIMV5sDSRBRMzYdR6BDSpwnEQaLPOngjuRmgeDTz7lyTNWgx1bkc/NSS3kORqr8FLeiSjyQ7ZFHP1vnJUQ8duj8SdTujPrHVZgDniTuTjq+cRW5TKCsUQEW1jUgyJo0wh3XCwvem7w+QkF2azh3Tb2zfecpaoWIPLlmjiv8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741186586; c=relaxed/simple; bh=eCzs6z/1ZaCc9kZkxUuGSc2H1XvV4MIOgYBJbjL04NU=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=BpEGoAeJXlkitALd4xwl32Y/v7FML1MdRJmv/rlvSd5Lt3oVCiK/wA8Sfi3+utRT8N66ypQ3P/yoS+XLSUiwSh/hHfZcQ5d/m9PMrHY2EAJo4UPn2vT51lNG78sNlrfXGPKhXCTlsUrVbthUVdxlko4O4QuCsmFqHk9zUGJrVOE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me; spf=pass smtp.mailfrom=pm.me; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b=RE7qFyrB; arc=none smtp.client-ip=185.70.43.22 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pm.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pm.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.b="RE7qFyrB" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1741186582; x=1741445782; bh=lNsOywLr42ifpKIYbHm0FRmw4MVYLujGcEk8RLbJlYg=; 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:List-Unsubscribe:List-Unsubscribe-Post; b=RE7qFyrBqjco0UkDuwTf/31sqOEGMwi5fVniTj5VVCpoHVPGUuV1Ow7XlTo0HsFRz 9YSb1M1Cu9NrdEwikTjKKQ+cWX1KxRF4i963UxwecIr3jQooJ/Eh0ELVmVqouqtnZP 1n37eVbq9KLCkaKhYCmZwp84m4DBS7sve7KqlCfebxUbf/ZXOFgvi1jb50iVTiK6ol tQjOGBdB3eHUtO0iWY4URiOBMMXgkEUgNUpGgiS1Z4vma6QUv2noSoIJJee6JWJQ0z kdgw9U7aV+PCBGtNtFLt9wBS9UA8MIjlFzvGLzfEuy6qTRRCTOQS3IrLleBBt40+Wd I4XYbwlUy61aw== Date: Wed, 05 Mar 2025 14:56:15 +0000 To: Alice Ryhl From: Oliver Mangold Cc: Miguel Ojeda , Alex Gaynor , Boqun Feng , Gary Guo , =?utf-8?Q?Bj=C3=B6rn_Roy_Baron?= , Benno Lossin , Andreas Hindborg , Trevor Gross , rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4] rust: adding UniqueRefCounted and UniqueRef types Message-ID: In-Reply-To: References: <20250305-unique-ref-v4-1-a8fdef7b1c2c@pm.me> Feedback-ID: 31808448:user:proton X-Pm-Message-ID: 375abdb427c4e02d70ff4548d076416d6c4e46a7 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 Hi Alice, On 250305 1339, Alice Ryhl wrote: > On Wed, Mar 05, 2025 at 11:31:44AM +0000, Oliver Mangold wrote: >=20 > > +impl Deref for UniqueRef { > > + type Target =3D T; > > + > > + fn deref(&self) -> &Self::Target { > > + // SAFETY: The type invariants guarantee that the object is va= lid. > > + unsafe { self.ptr.as_ref() } > > + } > > +} >=20 > What stops people from doing this? >=20 > let my_unique: UniqueRef =3D ...; > let my_ref: &T =3D &*my_unique; > let my_shared: ARef =3D ARef::from(my_ref); >=20 > Now it is no longer unique. > Oh, indeed. That's a serious problem. I see 2 options to deal with that: 1. remove ARef::From<&T> I checked the users of this, and it looks to me like there is rather a limited number and they are easy to fix by replacing the &T with ARef. But I assume that wouldn't be welcome as it is intrusive nonetheless and of course there is ergonomic value in having the function around. 2. add some new traits so implementers can opt in/out of that function. Basically one would have to pick if one wants to ARef::From<&T> or UniqueRef for one's type. > > +impl DerefMut for UniqueRef { > > + fn deref_mut(&mut self) -> &mut Self::Target { > > + // SAFETY: The type invariants guarantee that the object is va= lid. > > + unsafe { self.ptr.as_mut() } > > + } > > +} >=20 > This DerefMut will make it almost impossible for C types to implement > UniqueRefCounted because it is incompatible with pinning. You probably > want `T: UniqueRefCounted + Unpin` here. >=20 > For `T: !Unpin` (i.e. almost all C types), you can at most produce an > `Pin<&mut Self>`. I think I only understand 70% of that incompatiblity, but I will do a bit more reading. In any case I think I can work around that, but doing as you say, and maybe adding an extra method deref_pin() to get a pinned reference. Best, Oliver