From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f74.google.com (mail-wm1-f74.google.com [209.85.128.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DBA4B14BFA2 for ; Fri, 2 May 2025 08:35:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.74 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746174940; cv=none; b=hfO4T5xf0FpAU5NdLJP1vTmvjDtO0ZNHTS9aaIyFpDXH2w40Ss6x5Wpcf4GkyX2GWmguVRRN0cyW3e/O6JmxaalL0PLrL+4RkZuhsL4fKSyKSWMd2qqg0M9xjKvTOe0wFslTzvSjTv8HW290tsATpvULF8DTyjy8ka4rm+3UwvU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746174940; c=relaxed/simple; bh=LUBY75erqJBugAhNu+5GPQ9ZxN0mQ9SsLVRTeLJn3zs=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=qIl7h0NBCDEme+CeGH+NDaLdzLWpTPbGe0he2G6gP8Vds7hjBEdxtbHxzYjLaoR5IRBdlWnG+h7FXjfE62VqQtBGMYK5bsW/RqBOJUtBFxEWOrnlRQz02+EZ8y/oVWkMu10dC7j1mzWV+lRLQMIycMeFMBLofkDA1t8OonT61cU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--aliceryhl.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=lHBPwyTa; arc=none smtp.client-ip=209.85.128.74 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--aliceryhl.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="lHBPwyTa" Received: by mail-wm1-f74.google.com with SMTP id 5b1f17b1804b1-43f405810b4so8336985e9.1 for ; Fri, 02 May 2025 01:35:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1746174937; x=1746779737; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=f7r6WR049enygy037lONQ9m9pD13OBTo4e15DUJyoKE=; b=lHBPwyTa1A7MHnIeD2Ba9CUh5JzMIrcQ/qkuTgNmt7BO3hWaSSqfq72FH/WugH21or 6pPy6tPulSkQnkogT9oUOKGR5HTQQzyz2bAVrLb/he0sN25DbJK7CNW0ez4bnrvPVAHu tA67e72bjpqltxxwKjuK8yoLR+fIPcGAIge+V7V4Bo8IDEv8R+BlY92KZzMqFDr6vaDL MqCBwbiHrToi202x/zP/2PGogcREm6BsPI+9eYFcPVB7pxe51j0u/mM8GD9uevcHMofq 2ELgc0Qv1lm+TPsBsK4r9sY7gEy59pnL80/0Zpcc3Fp0c5Ct8FjlQ+dJnMJupLcVOTLD V82A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746174937; x=1746779737; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=f7r6WR049enygy037lONQ9m9pD13OBTo4e15DUJyoKE=; b=IFg872b/p171kdBPPUW/2CLIWjMFuHQiRHwvHyKfqEYWvF4kzbJHYztX99sxLFlaqW 2vGAp7ayDjJHrMpnMyoQZPYMgqI5hfmAqcJDJkZ8WXcVgVcDIreJ5aTjpa74Exbhmp6h y4T2Ifo57vGzoEC0lHsn8xSgD/Evg4O1Jn6//eQF3BTB+SOtkBEZrWQAc1/DT+k7sHaQ CD4J2lJ2m3l5wxccFJHHPkBU9CN75+iyKYo6Fuo+7h7/eP4xqbMA7IANE7ajL9RWfzm2 K9FcmqOHWfLqRjRp/5phn0aBl4KijLcDPYslrRKTcWYJYGjB0qpAeeyg40jKlvb9YYLa k3XQ== X-Forwarded-Encrypted: i=1; AJvYcCXoMXl1JVkurxGuSXz9HS+Rrziob2mwpVCKSYZ3BMSyNCYzHCYGEXR2hujIP5P6bFyCjqb5JvSlAgZX9w0FXA==@vger.kernel.org X-Gm-Message-State: AOJu0Yw8kC8GwxF4nDMA986/GUvzuINBS81wmSGPJ6qNulcS/EaELSs2 k/RKwBcNGEnQRj093eVrMAX14SLRsQqhysvTdRPO9p/vY7k9ja1nrLLH378qWB1iyg5v2XJHC/k GYx9d2hToeZfMjg== X-Google-Smtp-Source: AGHT+IGJkCdyZwfRFOBv6xVkehjXZ02i6s82Mg6JkS5KgBztkzCNpCn2kt3Ktou857DyL5RBsEPF7VOnppmsNZo= X-Received: from wmbjg12.prod.google.com ([2002:a05:600c:a00c:b0:43c:eaf6:525e]) (user=aliceryhl job=prod-delivery.src-stubby-dispatcher) by 2002:a05:600c:820d:b0:43c:f8fc:f69a with SMTP id 5b1f17b1804b1-441bbe98fbbmr16071135e9.4.1746174937358; Fri, 02 May 2025 01:35:37 -0700 (PDT) Date: Fri, 2 May 2025 08:35:35 +0000 In-Reply-To: Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250430-rust_unsafe_pinned-v2-0-fc8617a74024@gmail.com> <20250430-rust_unsafe_pinned-v2-1-fc8617a74024@gmail.com> <7bc9f839-a69a-4819-ba6d-36eadd8776b3@gmail.com> Message-ID: Subject: Re: [PATCH v2 1/3] rust: add UnsafePinned type From: Alice Ryhl To: Christian Schrefl Cc: Benno Lossin , Sky , Miguel Ojeda , Alex Gaynor , Boqun Feng , Gary Guo , "=?utf-8?B?QmrDtnJu?= Roy Baron" , Benno Lossin , Andreas Hindborg , Trevor Gross , Danilo Krummrich , "Gerald =?utf-8?Q?Wisb=C3=B6ck?=" , Ralf Jung , linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org Content-Type: text/plain; charset="utf-8" On Fri, May 02, 2025 at 02:08:13AM +0200, Christian Schrefl wrote: > [cc Ralf] > > On 02.05.25 12:51 AM, Benno Lossin wrote: > > On Thu May 1, 2025 at 9:11 PM CEST, Christian Schrefl wrote: > >> On 01.05.25 8:51 PM, Benno Lossin wrote: > >>> On Wed Apr 30, 2025 at 7:30 PM CEST, Christian Schrefl wrote: > >>>> On 30.04.25 11:45 AM, Benno Lossin wrote: > >>>>> On Wed Apr 30, 2025 at 10:36 AM CEST, Christian Schrefl wrote: > >>>>>> +/// This implementation works because of the "`!Unpin` hack" in rustc, which allows (some kinds of) > >>>>>> +/// mutual aliasing of `!Unpin` types. This hack might be removed at some point, after which only > >>>>>> +/// the `core::pin::UnsafePinned` type will allow this behavior. In order to simplify the migration > >>>>>> +/// to future rust versions only this polyfill of this type should be used when this behavior is > >>>>>> +/// required. > >>>>>> +/// > >>>>>> +/// In order to disable niche optimizations this implementation uses [`UnsafeCell`] internally, > >>>>>> +/// the upstream version however will not. So the fact that [`UnsafePinned`] contains an > >>>>>> +/// [`UnsafeCell`] must not be relied on (Other than the niche blocking). > >>>>> > >>>>> I would make this last paragraph a normal comment, I don't think we > >>>>> should expose it in the docs. > >>>> > >>>> I added this as docs since I wanted it to be a bit more visible, > >>>> but I can replace the comment text (about `UnsafeCell`) with this paragraph > >>>> and drop it from the docs if you want. > >>> > >>> I think we shouldn't talk about these implementation details in the > >>> docs. > >> > >> Alright, what do you think of: > >> > >> // As opposed to the upstream Rust type this contains a `PhantomPinned`` and `UnsafeCell` > > > > There are two '`' after PhantomPinned. > > > >> // - `PhantomPinned` to avoid needing a `impl !Unpin for UnsafePinned` > > > > s/ a / an / > > > > I find the phrasing 'avoid needing ' a bit weird, I'd > > just say "`PhantomPinned` to ensure the struct always is `!Unpin` and > > thus enables the `!Unpin` hack". > > Thanks I'll use that. > > > > > If you have a link to somewhere that explains that hack, then I'd also > > put it there. I forgot if it's written down somewhere. > > I haven't found anything that describes the hack in detail. > From what I understand its a combination of disabling `noalias` > [0] (this PR enables it for `Unpin` types) and disabling > `dereferencable` [1] on `&mut !Unpin` types. > Related rust issue about this [2]. > > Maybe Alice, Ralf or someone else form the rust side can provide > a better reference? > > [0]: https://github.com/rust-lang/rust/pull/82834 > [1]: https://github.com/rust-lang/rust/pull/106180 > [2]: https://github.com/rust-lang/rust/issues/63818 I wrote this a long time ago: https://gist.github.com/Darksonn/1567538f56af1a8038ecc3c664a42462 But it doesn't really take the angle of explaining the !Unpin hack. It's more of an early doc arguing for having an UnsafePinned type. Alice