From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f73.google.com (mail-ed1-f73.google.com [209.85.208.73]) (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 290442BEC5A for ; Wed, 21 Jan 2026 13:09:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.73 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769000977; cv=none; b=A2SkliE05NJKXuhgIxz33J2jqk+suQKJ6dLCSdKUzr9MqPCmU50fFtl2M3yx5+CUPEhEHnlrB9dFwRX/Pz9kJqBhNTVtI9sXCaOW+U+3LGItwe4XzivzfXqeitenYiJTUr6tdibIeor6Ihsuj9h9fFnRU0Xk7VcP37tT5bjUnEY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769000977; c=relaxed/simple; bh=+ZSgzFr1hrskbYz2DqxBWD0sKH/BKI4m7f4BLrv9im8=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=bjyr4pU/JxI29G5FH+u7u75YohrWdojr4E41iT7paqUaz6q7qKfkbU04I+PvrXCIiD8bIGMtHhtBcPzJzX6vzg8gxh7p1TS/6sdq80QwPtQ22PazQoekkqKTuAp5SsCQ/SjYQYzAxGPZFxsec5Ok4t0BZWIFF6XRd7szxIAzzWY= 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.73 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-f73.google.com with SMTP id 4fb4d7f45d1cf-64b735f514dso7210322a12.3 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=tfxuzycc8zC36cQiBFkNKeidmfjl5/uLPlgysUGHD5vONMmyp7pa6W/5anMhsWBwJL KAMcGhl7emZ98UwWNj5kj7koePsA56bsf6sOs3oOjt6iLfO3r+cT/WN0gWbf0bxhD9pE RtXyubP5ymZSA6RbLDyaenVxIrJ8Hm1T9WYopY5DHKYRTr1XuuGdn8nN4FOrkJIpXX+9 J1A/BuSL44aYkhtrjVhZniOcullaAKAGgcyfV3ve7k/5nYefobS4KWHOUm54iUxQG2NM a8dlpLgfUFhGSUhIgGfbMuAAs5FaAFJfx3T7bN19pCY40hw5CLngLYpkZDEsyZq7TOZb XYhw== X-Forwarded-Encrypted: i=1; AJvYcCXpafMHsMr/MX5qrmn1sk+QrWfolS9mZu11bIfoGe2VJA1eSvuRmKrizbHh/aoSpSDwtB7nVE/2RflIv/s=@vger.kernel.org X-Gm-Message-State: AOJu0YzMzq1PRAeIcAXKMcDXLcT2DMw0/LcmQZi5KRkNZi24y+vx1243 blryEQ5cCi2BTEMN+PWWtkvBw+A8sVMxrTFjMlOdAXnqEUu5JkIMFXIZ+67vf3POYPhd0QyiQAa IDba0e7BdsMiAta7vfQ== 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-kernel@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