From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dy1-f179.google.com (mail-dy1-f179.google.com [74.125.82.179]) (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 5285A3328E2 for ; Wed, 21 Jan 2026 14:49:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769006945; cv=none; b=gLJLRDZto0cfLSrsbyo9MdCKCFI61IiP+rZtwzV8bJ+BwVGRbKbMh6Rk6xF446JycsRPSzkLyVrN1i69kO8z/aoBLwlbbL9xUzrCAXKEFvGvYtw5MmkpqWwj6eHkt+QFwZksVPlA5sGH8dzyO3Lix687ZnlK8Ra9guG1aAArjMk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769006945; c=relaxed/simple; bh=JO/s/6KKvqMhoj8pQ+M8dYm9bOMaDHK5abW2HtiJvOQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=XYwQkvl7X65hL6mY+KhQIoPaS9v1R4xuF5shU7LBghI4cfiEATNPa1jVQLIwNhL1BEak14V8wf32LALkA9/GNcVHxc88krmZpDS2BQMrXwX/DZS2mPBc+1wqIfc5qwK0BiRGAcsslmaZEK8i9nL9km0ABZ4ChRAhaR9Sr0z6FI8= 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=SLx/LMJS; arc=none smtp.client-ip=74.125.82.179 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="SLx/LMJS" Received: by mail-dy1-f179.google.com with SMTP id 5a478bee46e88-2ae2eb49b4bso13401435eec.0 for ; Wed, 21 Jan 2026 06:49:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769006941; x=1769611741; 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=BLcZMH22PMLngVZW1Pr6WIQb6BYdcrFZicgkGSpRFnU=; b=SLx/LMJSCEasP6Wmrm0XBmx8QAs0wYn+/6mIWJFetcVqf5umUy9+2utkwHsmca7YZe UlgcoDoHZcEO0Z9iIm8xLPBI0w3saWK5D3BlJW5uUQzHY1PKM1v2Fg8RvHFw/vApe2Ot RZZSqll7Bql/b1N0lRwRE/DqcktX/Jlaw77ZE/xnwgPk8OvWyehKQ8pY5ZxWrafdhbjd I4yMIJPvowuoUfJv2URmGWQpV6py2EKNfAB1KbYv4IT6uWvFRXMBhOnB+Ej6rlsfWn97 Ny3uCdaJNxO0nCKua72n1n2ojbGrZjk87oUs7V4tFWAVIiP5eyIk6BSmWqmD3e5rLOcg E59Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769006941; x=1769611741; 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=BLcZMH22PMLngVZW1Pr6WIQb6BYdcrFZicgkGSpRFnU=; b=v6aImrOSaywuRKGrCciYwdIQOtBDpWck0OAVSnKXGMY3CWh1dRzO14nwnoxbzLX3pI /RICwlw/rGHxvNqF1jbmb+9Xo+a0vAMTCif6ZezmYZLnx+xqQig3iRJ3IsUKkD35tseF PCqopeWQiZ/XzxaR9O6cAsXONP3/HAJwAuwmKfM2fljx6t0pJZkfQIXQk3lHkCYZtRFh Vpu8AeDg2eiFqSjXLZhrUxRXsytuUI4KOKBPMTPpcv925hk9vQkauIQ0kJIpe9jRSsbp MpxlK7tgd+Aj8VedPCW8m1NkduyCCp91tpj58dWUzMJQgEFH0G4LhxRe4ywpIv1kxcVu 6B9w== X-Forwarded-Encrypted: i=1; AJvYcCVA9YPNMPI7/qYGkEEp+SPZiInlvEcTmLreQN+r7hOL8usfR2nD+tvy2cPBAYkVZbsxBoEjT70bM192yyc=@vger.kernel.org X-Gm-Message-State: AOJu0YwKtEQUtcmFStojsHjynY50XaglaPJOdVjxpIcTpytOKIQC//qH dixvfTu2DBioFAVHmw3nat2mj3YqncO+0bSu8JSDQhxySEI9wu3EWKKH57Bv4GTf X-Gm-Gg: AZuq6aLMPfqyOMph703zkOYXmZ5xVGDnYp8mKODUIvqoMGQLtAACln0Jt6TVLBHV/Lm LqBMGVBHRrBUyBd+PFa7BDobLYkkl8hwZ064KK6T+JXdi7Bfz3ewNmnRpLroGFJbYRq/422PT5c w9IBMvRsPVPIUa0ahsHp4iIWXyEX4eJB7dYO5fNqwU2/cVA4qskQklLjXYBSZP3HS6u5ON0jWOy VZ0QhkUPzOASKWOHyPx6sRUyZgEG64DJy8UfjC7yccHKAUuMKBheOojkpNEk2z/Oo/VTDPC1LWP GWzXF6CrbwZrDl+1TmT5DYY8AlxJP6YGbpejSSY5b/ugjoyYGJFm0g9o6mWPR40vcvrVrjc29HQ A5anxRSmpTYQupJnpoy40kqVKdqZQkzbwjViN756k1ip4mtkmyYaQOi0szovuM5yA365NCE8JmA PVyoPeO5muaNqRp8KES9edUswjOzu8Ao3Dt1md6vdYNo0cAZSWHcmb4Zp5fL1xgN6ubNVrcgW9g V57JIlguHytMLk= X-Received: by 2002:ac8:5a8a:0:b0:502:9abf:a89f with SMTP id d75a77b69052e-502d85074d8mr56654461cf.41.1769000304933; Wed, 21 Jan 2026 04:58:24 -0800 (PST) Received: from fauth-a2-smtp.messagingengine.com (fauth-a2-smtp.messagingengine.com. [103.168.172.201]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-502a1d9f480sm112557811cf.13.2026.01.21.04.58.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Jan 2026 04:58:24 -0800 (PST) Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfauth.phl.internal (Postfix) with ESMTP id 9287AF40068; Wed, 21 Jan 2026 07:58:23 -0500 (EST) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-05.internal (MEProxy); Wed, 21 Jan 2026 07:58:23 -0500 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddugeeffeegucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvfevuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepuehoqhhunhcu hfgvnhhguceosghoqhhunhdrfhgvnhhgsehgmhgrihhlrdgtohhmqeenucggtffrrghtth gvrhhnpeeftdevhfevteettdfgffeigfekieetudejgfdukeeihfffheehueevleffkeef vdenucffohhmrghinheplhhptgdrvghvvghnthhsnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomhepsghoqhhunhdomhgvshhmthhprghuthhhphgv rhhsohhnrghlihhthidqieelvdeghedtieegqddujeejkeehheehvddqsghoqhhunhdrfh gvnhhgpeepghhmrghilhdrtghomhesfhhigihmvgdrnhgrmhgvpdhnsggprhgtphhtthho pedvtddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepvghlvhgvrhesghhoohhglh gvrdgtohhmpdhrtghpthhtohepghgrrhihsehgrghrhihguhhordhnvghtpdhrtghpthht oheplhhinhhugidqkhgvrhhnvghlsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpth htoheprhhushhtqdhfohhrqdhlihhnuhigsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhr tghpthhtoheplhhinhhugidqfhhsuggvvhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhrgh dprhgtphhtthhopehkrghsrghnqdguvghvsehgohhoghhlvghgrhhouhhpshdrtghomhdp rhgtphhtthhopeifihhllheskhgvrhhnvghlrdhorhhgpdhrtghpthhtohepphgvthgvrh iisehinhhfrhgruggvrggurdhorhhgpdhrtghpthhtohepmhgrrhhkrdhruhhtlhgrnhgu segrrhhmrdgtohhm X-ME-Proxy: Feedback-ID: iad51458e:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 21 Jan 2026 07:58:22 -0500 (EST) Date: Wed, 21 Jan 2026 20:58:21 +0800 From: Boqun Feng To: Marco Elver Cc: Gary Guo , linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org, linux-fsdevel@vger.kernel.org, kasan-dev@googlegroups.com, Will Deacon , Peter Zijlstra , Mark Rutland , Miguel Ojeda , =?iso-8859-1?Q?Bj=F6rn?= Roy Baron , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , Danilo Krummrich , Elle Rhumsaa , "Paul E. McKenney" , FUJITA Tomonori Subject: Re: [PATCH 2/2] rust: sync: atomic: Add atomic operation helpers over raw pointers Message-ID: References: <20260120115207.55318-1-boqun.feng@gmail.com> <20260120115207.55318-3-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 Wed, Jan 21, 2026 at 01:13:57PM +0100, Marco Elver wrote: > On Tue, 20 Jan 2026 at 23:29, Boqun Feng wrote: > [..] > > > > > READ_ONCE is meant to be a dependency-ordering primitive, i.e. be more > > > > > like memory_order_consume than it is memory_order_relaxed. This has, to > > > > > the best of my knowledge, not changed; otherwise lots of kernel code > > > > > would be broken. > > > > Our C's atomic_long_read() is the same, that is it's like > > memory_order_consume instead memory_order_relaxed. > > I see; so it's Rust's Atomic::load(Relaxed) -> atomic_read() -> > READ_ONCE (for most architectures). > > > > > On the Rust-side documentation we mentioned that `Relaxed` always preserve > > > > dependency ordering, so yes, it is closer to `consume` in the C11 model. > > > > > > Alright, I missed this. > > > Is this actually enforced, or like the C side's use of "volatile", > > > relies on luck? > > > > > > > I wouldn't call it luck ;-) but we rely on the same thing that C has: > > implementing by using READ_ONCE(). > > It's the age-old problem of wanting dependently-ordered atomics, but > no compiler actually providing that. Implementing that via "volatile" > is unsound, and always has been. But that's nothing new. > > [...] > > > > I think this is a longstanding debate on whether we should actually depend on > > > > dependency ordering or just upgrade everything needs it to acquire. But this > > > > isn't really specific to Rust, and whatever is decided is global to the full > > > > LKMM. > > > > > > Indeed, but the implementation on the C vs. Rust side differ > > > substantially, so assuming it'll work on the Rust side just because > > > "volatile" works more or less on the C side is a leap I wouldn't want > > > to take in my codebase. > > > > > > > Which part of the implementation is different between C and Rust? We > > implement all Relaxed atomics in Rust the same way as C: using C's > > READ_ONCE() and WRITE_ONCE(). > > I should clarify: Even if the source of the load is "volatile" > (through atomic_read() FFI) and carries through to Rust code, the > compilers, despite sharing LLVM as the code generator, are different > enough that making the assumption just because it works on the C side, > it'll also work on the Rust side, appears to be a stretch for me. Gary > claimed that Rust is more conservative -- in the absence of any > guarantees, being able to quantify the problem would be nice though. > I don't disagree and share the similar concern as you do. > [..] > > > However, given "Relaxed" for the Rust side is already defined to > > > "carry dependencies" then in isolation my original comment is moot and > > > does not apply to this particular patch. At face value the promised > > > semantics are ok, but the implementation (just like "volatile" for C) > > > probably are not. But that appears to be beyond this patch, so feel > > > > Implementation-wise, READ_ONCE() is used the same as C for > > atomic_read(), so Rust and C are on the same boat. > > That's fair enough. > > Longer term, I understand the need for claiming "it's all fine", but > IMHO none of this is fine until compilers (both for C and Rust) > promise the semantics that the LKMM wants. Nothing new per-se, the > only new thing here that makes me anxious is that we do not understand > the real impact of this lack of guarantee on Linux Rust code (the C > side remains unclear, too, but has a lot more flight miles). Perhaps > the work originally investigating broken dependency ordering in Clang, > could be used to do a study on Rust in the kernel, too. You mean this: https://lpc.events/event/16/contributions/1174/ ? If so, that'll be great! I believe if we could learn about how Rust compiler can mess up with dependency ordering, it'll be a very helpful resource to understand how we can work with Rust compiler to resolve it in a pratical way. I believe that work was LLVM-based, so it should apply to Rust code as well, except that we may need to figure out what optmization the Rust front end would do at MIR -> LLVM IR time that could affect dependency orderings. Regards, Boqun