From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 C75B319F464; Wed, 20 Aug 2025 10:51:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755687080; cv=none; b=OxEZs8Tu5bdzMt90PW0BgD1TuQBdTDh317PVvtBVq81gGcISw8nQjlVgdw6ctmqMJeIGUXMPcTMvJ9mEDGlLd1RMcnuw6iJ1fFiBM7Ve9ZmZd5ANJh7IEbsXB5RFKLPFF+c2sSPEaif09C4r2/nTEbkGz+NAuCR2KvbD2tv3S0Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755687080; c=relaxed/simple; bh=ftbWhPhTq0/pc2ywQ/3r5J1AkPH0jYGq+ptt1+mIhBs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=jRk2h20mD8GdE3Y4WwBaDPo0dYyWasV1ob9k9lg/6UXQEnA5C+aCehP3XK4giRnhhf3ySUXugmTSY/9pV3EpqFdAxWQBpazau1y+wSrAmSl4fYzxy9NrH84oxiw2crnrM8ZGuMzVu77N+qJEXjEyDuYbKfZ/RIJvimHO+HCt+54= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nqJ76beM; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="nqJ76beM" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2BC86C4CEED; Wed, 20 Aug 2025 10:51:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1755687080; bh=ftbWhPhTq0/pc2ywQ/3r5J1AkPH0jYGq+ptt1+mIhBs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=nqJ76beMYiRpjoyvlQeZ6dc3cSkWRnEc4ZZ5xiokGOVHnZSQBW6SjieH3ISBkk+uk s506k4mrJW4FMT7+NvRKP4DdFTG9uRfJQytOq50mmtOAd6ukL4DtliCtvEv7650xWA Z67zU3KxQKvAJ/JK5A0mgp82UrActZansn1Uk3CD5TjruyLeFuu/TXwYdjlhDtMnRm NnG2bBuJ+Sj/GYHlm1mc7I0PthfE4jKKtKqIdfZg1Cbra2LeC9qJnACC5LgJY9W390 BXSx83r8vuW6sfcKaZIfGnwamOd4JcXpzSOburokesg5KbpjqJdozKBBLHMGTVhgIp MlD/7rqxCiryA== From: Andreas Hindborg To: Oliver Mangold , Benno Lossin Cc: Miguel Ojeda , Alex Gaynor , Boqun Feng , Gary Guo , =?utf-8?Q?Bj=C3=B6rn?= Roy Baron , Alice Ryhl , Trevor Gross , Asahi Lina , rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v11 1/4] rust: types: Add Ownable/Owned types In-Reply-To: References: <20250618-unique-ref-v11-0-49eadcdc0aa6@pm.me> <87ldnfd766.fsf@t14s.mail-host-address-is-not-set> Date: Wed, 20 Aug 2025 12:51:12 +0200 Message-ID: <875xeicllr.fsf@t14s.mail-host-address-is-not-set> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain "Oliver Mangold" writes: > On 250820 0941, Benno Lossin wrote: >> On Wed Aug 20, 2025 at 8:02 AM CEST, Oliver Mangold wrote: >> > On 250819 1913, Benno Lossin wrote: >> >> On Tue Aug 19, 2025 at 10:53 AM CEST, Andreas Hindborg wrote: >> >> > "Benno Lossin" writes: >> >> >> On Tue Aug 19, 2025 at 8:04 AM CEST, Oliver Mangold wrote: >> >> >>> On 250819 0027, Benno Lossin wrote: >> >> >>>> On Mon Aug 18, 2025 at 3:04 PM CEST, Oliver Mangold wrote: >> >> >>>> > On 250818 1446, Andreas Hindborg wrote: >> >> >>>> >> "Oliver Mangold" writes: >> >> >>>> >> > +impl DerefMut for Owned { >> >> >>>> >> > + fn deref_mut(&mut self) -> &mut Self::Target { >> >> >>>> >> > + // SAFETY: The type invariants guarantee that the object is valid, and that we can safely >> >> >>>> >> > + // return a mutable reference to it. >> >> >>>> >> > + unsafe { self.ptr.as_mut() } >> >> >>>> >> > + } >> >> >>>> >> > +} >> >> >>>> >> >> >> >>>> >> I think someone mentioned this before, but handing out mutable >> >> >>>> >> references can be a problem if `T: !Unpin`. For instance, we don't want >> >> >>>> >> to hand out `&mut Page` in case of `Owned`. >> >> >>>> >> >> >> >>>> > >> >> >>>> > That was the reason, why `OwnableMut` was introduced in the first place. >> >> >>>> > It's clear, I guess, that as-is it cannot be implemented on many classes. >> >> >>>> >> >> >>>> Yeah the safety requirements ensure that you can't implement it on >> >> >>>> `!Unpin` types. >> >> >>>> >> >> >>>> But I'm not sure it's useful then? As you said there aren't many types >> >> >>>> that will implement the type then, so how about we change the meaning >> >> >>>> and make it give out a pinned mutable reference instead? >> >> >>> >> >> >>> Making `deref_mut()` give out a pinned type won't work. The return types of >> >> >>> deref() are required to match. >> >> >> >> >> >> I meant the changes that Andreas suggested. >> >> > >> >> > Not sure what you are asking, but I need to assert exclusive access to >> >> > an `Page`. I could either get this by taking a `&mut Owned` or a >> >> > `Pin<&mut Page>`. I think the latter is more agnostic. >> >> >> >> The former isn't really correct? It's like having a `&mut Box` >> >> which is weird. I was saying we can have a `DerefMut` impl gated on `T: >> >> Unpin` and a `fn get_pin_mut(&mut self) -> Pin<&mut T>`. >> > >> > Yes. I think `Page` is the wrong example, as it already has owned semantics >> > and does its own cleanup. Wrapping it in an Owned would be redundant. >> >> After we have these owned patches, we are going to change `Page` to >> `Opaque`. > > Ah, okay. Makes sense, I guess. I applied Linas patch with this change to my tree [1]. Best regards, Andreas Hindborg [1] https://lore.kernel.org/all/20250202-rust-page-v1-2-e3170d7fe55e@asahilina.net/