From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f44.google.com (mail-dl1-f44.google.com [74.125.82.44]) (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 A4A1B238C3B for ; Sun, 18 Jan 2026 05:59:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768715956; cv=none; b=sN61af28WcgGu+J4dmQEljNPm8meJ2BCb9Pk++MPtPtDSt91wm1RWrLcaAYN2424IYqhJEQn14dn1/eYBWz1gKR2dSq7Y0vAWYyIWOtg5If7TMBdIe00jddU/f1EuhEL9/G8ebTMJzN8kGVXcHu8g+RN0kuRzmHv5VHK97zmrJE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768715956; c=relaxed/simple; bh=DIXu1xJBWswCmGBRxFXgpv7cNPr9e4eOhTTy17+c9Oc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=XONFmexSrHY7/WIZQaLT1CqvML4Z9Ceo/tLwnXJf6pBgiIWxKCiscjnxDmirwDZa+P6pU5g2hQCN5JgdEPuUKXZzMOQWdArcYP5qbJkpkjoD+BO7uarwGBAW8D7RIpq5b993aWIQQs2QFpG7ZH7i8W2OJ0niOIt7xqoQ/72Nsfc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=LGukHylj; arc=none smtp.client-ip=74.125.82.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="LGukHylj" Received: by mail-dl1-f44.google.com with SMTP id a92af1059eb24-12332910300so3309545c88.0 for ; Sat, 17 Jan 2026 21:59:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768715954; x=1769320754; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:feedback-id:from:to:cc:subject:date :message-id:reply-to; bh=sOiV0D+CNI6UsixBopTqJbDRkz4TgZfrfHbV+iHjkxE=; b=LGukHyljl0/pqNfavtKqnOwKjYzQqUqt6cdCb8uJ73oY+cREdct7hmT+9obDb1aoo/ qZGch4QthW7tteHoQwIF3lVclfN4/e20W1YxYnlKKiOeNxefAAw6GDOLVVy0Meu7BAJz bQTmQnhTIjWD87R0aO9nL8kbEGQFDKj4mcckF/HcuGGz7I+ZfsjwUM211khVpPwgGAo5 nIGQn/wspMI+tLNUSlqmq3g/NQHHpkQ76V0Z6WstIkgRb9MpF+CSPhI9/nh99ukyLSyq 9fU5BsJ4//bYCIP4z7E2+mlT4pIbazyA+PI3nauIx0eL4HonXIa27jJ1caJ/svMm0G4C TDcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768715954; x=1769320754; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:feedback-id:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=sOiV0D+CNI6UsixBopTqJbDRkz4TgZfrfHbV+iHjkxE=; b=xKJ6DTJXmYpSM6z/MQ5R3rQmqD9M1p4LFrURtCqwNMWgOpq/tgj31aL1jadcAe4RNS TdnZXea+JMIgNl/ZI9CUZaBn4zOaGaM70tZwYooDz9Ck7w/Pfkgufz8VwKgNwt8onvdb PaiTINpV4HslDp8RcZavOdZ7xBibJj8IWbf2suCXMw4LU499p7R4MZ/YuLtOyJ4TTQSK jhpR8mDe0vNkNdPcUEpwKnrQ/eybwQbqnrLSgk2bx9X9OsJVk16wf4MEuryI8/l3UWqT nSaOkGiNTrc++/NWrq96Rc5w3e+C8CRNsZVZuX0E4uS6rWFihCh1jsGHLJIOZn81Szi3 CxxA== X-Forwarded-Encrypted: i=1; AJvYcCXNfGVu5/WZIOVJYcTDof9I6FSRM29Uz0V9UrIv2LAN3eB0p/ay97rTOrx1ma3oAegVbM+lRUT2GOD/emE=@vger.kernel.org X-Gm-Message-State: AOJu0YxCtnaIUTnwPqAfDGCO7SBsZKzZ0BDAa8Z67IYUt0BkKhK74qua Yx/n8iixbon7UfrO3AKWzZCWXmiToaIbB4KO/guNqnl6hnbZptrJrrPP0VL1mYhJ X-Gm-Gg: AY/fxX5IsuqBSV+ez+mN5DPE+NoDKx1Rk4TXq1/68WoDF6l98zuAGLxv5U2YUzHt4dP i4cMU48CSt168iXP6N+Khzvaf65lENmvv4+DOJmI5AK5bKF0DNKmpttoV/kOl1OgegaqehXpjca 5nJC+UoJRTA3AHgUu6DYc7wijZmDc4kpfXUGX65a2sWWqHVW7efU/8rk/HefKyocxSr2cZb7Vu3 /nTdYKJffRdxzN0JQNh3VB/1yOOV5z3Dlwo3Yq/CML0Uhl6x4f2sLGvdimYMDxZyRXKUfDaQH5t vqc2EJpaX+vi+OqS6QEbTNniI2M/UsW5ogMG/t2QZ1WgObFVOaaNeS+B2VyEA/6WOuAK/DFx59a xa80+fA4GATTm21eskHSO0JMacep1fq7slpe8KS/tLzRbzK51rJALOZKsfg+7op67kG0ZssTtFx T/DPVYAdxR+aFFxjRVkHdCZkcJn1WvNDm9qWIPqSeW7kfBHj+uaqSdvXWUY3ncUsvyzDlfr9piW Uq6HOMNaKl4Pqg= X-Received: by 2002:a05:622a:14cb:b0:501:4b22:b9c0 with SMTP id d75a77b69052e-502a175e37dmr104860631cf.79.1768709979829; Sat, 17 Jan 2026 20:19:39 -0800 (PST) Received: from fauth-a1-smtp.messagingengine.com (fauth-a1-smtp.messagingengine.com. [103.168.172.200]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8942e6214c5sm54662016d6.25.2026.01.17.20.19.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 17 Jan 2026 20:19:39 -0800 (PST) Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41]) by mailfauth.phl.internal (Postfix) with ESMTP id 5F538F4007B; Sat, 17 Jan 2026 23:19:38 -0500 (EST) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-01.internal (MEProxy); Sat, 17 Jan 2026 23:19:38 -0500 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddufeefjeduucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvfevuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepuehoqhhunhcu hfgvnhhguceosghoqhhunhdrfhgvnhhgsehgmhgrihhlrdgtohhmqeenucggtffrrghtth gvrhhnpeehudfgudffffetuedtvdehueevledvhfelleeivedtgeeuhfegueevieduffei vdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsoh hquhhnodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdeiledvgeehtdeigedq udejjeekheehhedvqdgsohhquhhnrdhfvghngheppehgmhgrihhlrdgtohhmsehfihigmh gvrdhnrghmvgdpnhgspghrtghpthhtohepvdeipdhmohguvgepshhmthhpohhuthdprhgt phhtthhopehgrghrhiesghgrrhihghhuohdrnhgvthdprhgtphhtthhopehruhhsthdqfh horhdqlhhinhhugiesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehlihhn uhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehrtg husehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtohepohhjvggurgeskhgvrhhn vghlrdhorhhgpdhrtghpthhtohepsghjohhrnhefpghghhesphhrohhtohhnmhgrihhlrd gtohhmpdhrtghpthhtoheplhhoshhsihhnsehkvghrnhgvlhdrohhrghdprhgtphhtthho pegrrdhhihhnuggsohhrgheskhgvrhhnvghlrdhorhhgpdhrtghpthhtoheprghlihgtvg hrhihhlhesghhoohhglhgvrdgtohhm X-ME-Proxy: Feedback-ID: iad51458e:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 17 Jan 2026 23:19:37 -0500 (EST) Date: Sun, 18 Jan 2026 12:19:35 +0800 From: Boqun Feng To: Gary Guo Cc: rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, rcu@vger.kernel.org, Miguel Ojeda , =?iso-8859-1?Q?Bj=F6rn?= Roy Baron , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , Danilo Krummrich , Will Deacon , Peter Zijlstra , Mark Rutland , "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Josh Triplett , Uladzislau Rezki , Steven Rostedt , Mathieu Desnoyers , Lai Jiangshan , Zqiang , FUJITA Tomonori Subject: Re: [PATCH 4/5] rust: sync: atomic: Add Atomic<*mut T> support Message-ID: References: <20260117122243.24404-1-boqun.feng@gmail.com> <20260117122243.24404-5-boqun.feng@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Sat, Jan 17, 2026 at 05:03:15PM +0000, Gary Guo wrote: > On Sat Jan 17, 2026 at 12:22 PM GMT, Boqun Feng wrote: > > Atomic pointer support is an important piece of synchronization > > algorithm, e.g. RCU, hence provide the support for that. > > > > Note that instead of relying on atomic_long or the implementation of > > `Atomic`, a new set of helpers (atomic_ptr_*) is introduced for > > atomic pointer specifically, this is because ptr2int casting would > > lose the provenance of a pointer and even though in theory there are a > > few tricks the provenance can be restored, it'll still be a simpler > > implementation if C could provide atomic pointers directly. The side > > effects of this approach are: we don't have the arithmetic and logical > > operations for pointers yet and the current implementation only works > > on ARCH_SUPPORTS_ATOMIC_RMW architectures, but these are implementation > > issues and can be added later. > > > > Signed-off-by: Boqun Feng > > I am happy that this is now using dedicated helpers for pointers, and not going > through an intermediate integer which can lose provenance. > > Some feedbacks below, but in general LGTM. > > Reviewed-by: Gary Guo > Thanks! > > --- > > diff --git a/rust/kernel/sync/atomic.rs b/rust/kernel/sync/atomic.rs [...] > > index 4aebeacb961a..4d2a5228c2e4 100644 > > --- a/rust/kernel/sync/atomic.rs > > +++ b/rust/kernel/sync/atomic.rs > > @@ -51,6 +51,10 @@ > > #[repr(transparent)] > > pub struct Atomic(AtomicRepr); > > > > +// SAFETY: `Atomic` is safe to transfer between execution contexts because of the safety > > +// requirement of `AtomicType`. > > +unsafe impl Send for Atomic {} > > + > > // SAFETY: `Atomic` is safe to share among execution contexts because all accesses are atomic. > > unsafe impl Sync for Atomic {} > > > > @@ -68,6 +72,11 @@ unsafe impl Sync for Atomic {} > > /// > > /// - [`Self`] must have the same size and alignment as [`Self::Repr`]. > > /// - [`Self`] must be [round-trip transmutable] to [`Self::Repr`]. > > +/// - [`Self`] must be safe to transfer between execution contexts, if it's [`Send`], this is > > +/// automatically satisfied. The exception is pointer types that are even though marked as > > +/// `!Send` (e.g. raw pointers and [`NonNull`]) but requiring `unsafe` to do anything > > +/// meaningful on them. This is because transferring pointer values between execution contexts is > > +/// safe as long as the actual `unsafe` dereferencing is justified. > > I think the discussion about `Send` on pointers should be moved to the `impl > AtomicType for *mut T` side. > The reason I put something here was to answer the potential question "why don't you require AtomicType being a subtrait of Send?", that's more of a question for people who read about `AtomicType`, so I figured we need some explanation. But I'm fine if you think we should move some of the comments to the impl block, or we duplicate some. Although I don't think the current version is worse. Considering we do: /// - [`Self`] must have the same size and alignment as [`Self::Repr`]. /// - [`Self`] must be [round-trip transmutable] to [`Self::Repr`]. /// - [`Self`] must be safe to transfer between execution contexts, if it's [`Send`], this is /// automatically satisfied. for AtomicType, I'm not sure someone read about `AtomicType` could have everything they need to understand why it's not `: Send`. [...] > > +// SAFETY: > > +// > > +// - `*mut T` has the same size and alignment with `*const c_void`, and is round-trip > > +// transmutable to `*const c_void`. > > +// - `*mut T` is safe to transfer between execution contexts. See the safety requirement of > > +// [`AtomicType`]. > > +unsafe impl super::AtomicType for *mut T { > > + type Repr = *const c_void; > > +} > > How about *const T? > In general I want to avoid const raw pointers since it provides very little extra compared to mut raw pointers. For compiler optimization, provenenace is more important than "const vs mut" modifier, for dereference, it's unsafe anyway and users need to provide reasoning (including knowing the provenance and other accesses may happen to the same address), so I feel the type difference of "*const T" vs "*mut T" doesn't do anything extra either. Think about it, in Rust std, there are two pointer types only maps to "*mut T": NonNull (as_ptr() returns a `*mut T`) and AtomicPtr (as_ptr() returns a `*mut *mut T`). And there is no type like NonNullConst and AtomicConstPtr. This is a lint to me that we may not need to support `*const T` in most cases. But maybe I'm missing something? If you have a good reason, we can obviously add the support for `*const T`. Regards, Boqun > > + > > // SAFETY: `i32` has the same size and alignment with itself, and is round-trip transmutable to > > // itself. > > unsafe impl super::AtomicType for i32 { > > @@ -215,4 +226,16 @@ fn atomic_bool_tests() { > > assert_eq!(false, x.load(Relaxed)); > > assert_eq!(Ok(false), x.cmpxchg(false, true, Full)); > > } > > + > > + #[test] > > + fn atomic_ptr_tests() { > > + let mut v = 42; > > + let mut u = 43; > > + let x = Atomic::new(&raw mut v); > > + > > + assert_eq!(x.load(Acquire), &raw mut v); > > + assert_eq!(x.cmpxchg(&raw mut u, &raw mut u, Relaxed), Err(&raw mut v)); > > + assert_eq!(x.cmpxchg(&raw mut v, &raw mut u, Relaxed), Ok(&raw mut v)); > > + assert_eq!(x.load(Relaxed), &raw mut u); > > + } > > } >