From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f74.google.com (mail-ed1-f74.google.com [209.85.208.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 2DCDE3E8C56 for ; Wed, 21 Jan 2026 13:09:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.74 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769000976; cv=none; b=diB4SSeXS8bJ+IkMiTZsxGew/Ay/zGL+UipteCkz1xuiOkjN4nplz7wTnrjLyaE8Xsf6nfv37DN0zgYEUkiOFuG3UR6elIM23cSW2Jtx0b1CoYvaGMWbCPAnS1e0d9cfKPhAqmISpPdQJbyqA5Lbyg/6G895+ntElw5VHRFbPM4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769000976; c=relaxed/simple; bh=+ZSgzFr1hrskbYz2DqxBWD0sKH/BKI4m7f4BLrv9im8=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=YwrcF960v17dTq1769LpUiHAHJ/JGRrsGVH4/6Pfiw954CHoeZ6lNBXo8yGz73aP8uy6WIodKjAa0jS9Oq+ZJMqiMswjEeakKLJDpO5FxLus3brUu8yb5yZa96gOzDeqwRj80/sjrscyFPFqKdH79mJCKy+OvcbiV1SPYQdxvdg= 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=RgJJgEkL; arc=none smtp.client-ip=209.85.208.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="RgJJgEkL" Received: by mail-ed1-f74.google.com with SMTP id 4fb4d7f45d1cf-65821c9e5b7so322626a12.0 for ; Wed, 21 Jan 2026 05:09:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1769000973; x=1769605773; 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=e6EfVFXbq2W0nAFcvfXqkhYP0i8qGUxUjSq0sP59zac=; b=RgJJgEkLdNg2xg9OxjnWiiLXUrsQ9PemGinQ9GYe3uglW/sg+H41N3dtqz//q8A8d0 UeuYwiqOwnucTatXpga1MUyLkMrBYWjAI/0MR0+ajrUqy42DgtPCJ4fKTj+dprdAKHH2 1k4t2K5kvSRKPuI1CG5obX5MDbfbkLJYSOUBne1aMtzi9tu7TjpqBcpNdDAW4CLx30Wb YDNvb+UujEiiEQj1kJvNjixY6oRwShJqIQVnXzEDIkPKF0G2Cy/rti57UeOMBZjlLu0D axFGGq78XKJRjDqn4u2OYBH+M21bH12F+nUIy8SeTgS3PEZfR9/7hZSALh4sg0nlA5I1 VfFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769000973; x=1769605773; 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=e6EfVFXbq2W0nAFcvfXqkhYP0i8qGUxUjSq0sP59zac=; b=cu8kbe4MmUHuBDkBI6CIrqpPHZl/7iQtFzYdCwUva++AHRjBr7QfSDtpbcD2e9P8TK NR6PwZ+tC0/SQKUGXgSrmPodbuO/2Q0EjZ+l7WtenS2+RCDqYMjWoQUasv7pVX6qdrn/ K9NJM9x/P3QrDWQ/ViV/F/IyEwa5uRFsRdqAF9JPaP4mLQXuKzV/+STOb3pCHA80P7hR FwGiqb5Tj4+AhC5e8BVqZnBZP8G3Nw6fsxzqmZo9arrfagqrDM5oXgic3OnQoLobbeNI gV9i901xxLKk8OAaXyz/33eK9xoSy6SLpHcIwn48Ksxlj2F1VLSpCfmdzzgw+YEXgVYm Pt0g== X-Forwarded-Encrypted: i=1; AJvYcCVfo557OboKarg13A5HCgxGbI1hOCecWXUfi3QEmKgXRQV73NJEnX8Clu5ESy6suKzV84qZmAeB7sxI5x0l@vger.kernel.org X-Gm-Message-State: AOJu0Yx9oEAWSAxLSq31FGj5VxuUk9FPEbR16JbYGM/gatrDkqfJ6O79 69b5/rxLozoR2oEbhWQWUOIQq61+95Tugi4Q+z9xFoJjkohZu2qkra61Ao2E06olvpZLowuJ7L6 KTv9Kh68ydSlLEMoA3w== X-Received: from edrn25.prod.google.com ([2002:aa7:c459:0:b0:658:3f8:4209]) (user=aliceryhl job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6402:51d4:b0:658:2e5d:cc1 with SMTP id 4fb4d7f45d1cf-6582e5d1110mr308806a12.21.1769000973476; Wed, 21 Jan 2026 05:09:33 -0800 (PST) Date: Wed, 21 Jan 2026 13:09:32 +0000 In-Reply-To: Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260120115207.55318-1-boqun.feng@gmail.com> <20260120115207.55318-3-boqun.feng@gmail.com> Message-ID: Subject: Re: [PATCH 2/2] rust: sync: atomic: Add atomic operation helpers over raw pointers From: Alice Ryhl To: Marco Elver Cc: Boqun Feng , 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 , "=?utf-8?B?QmrDtnJu?= Roy Baron" , Benno Lossin , Andreas Hindborg , Trevor Gross , Danilo Krummrich , Elle Rhumsaa , "Paul E. McKenney" , FUJITA Tomonori Content-Type: text/plain; charset="utf-8" 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. > > [..] > > > 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. We did already have discussions with the Rust compiler folks about this topic, and they said that they are comfortable with Rust doing the exact same hacks as C since that should "work" in Rust for the same reasons it "works" in C. Alice