From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BA7D6256C for ; Thu, 26 Oct 2023 08:14:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="PcOA/EqA" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=7Ac2lsTLX6oaCFTK+hAgvsoBjk6RrYwjBJWA86xwxA8=; b=PcOA/EqANSQyrrzaA6ZNbON/qw 2GuUgXTosP7z60vDMEAt/QzqafvyRBZ/yV9b/kaPi23W8blMVIEjNfUphG9iltyG6Qi1mitrUR8Kj MRzl05qUDnGaLri4lil6C0/yAGD9swRKnKBjLPu2/B+H1Xg6nwz+Kt/rqUrmkCbKvZG8IffR5pSiK FTdf2fs6HmjryxBtpNoHkuMpvY92HNKF6pewQECWNib6WX6dAWjPaEZg3gCHdp+DGRQaVe0VOovTZ EA0d8v/nB2omlsg0EDU7ypHQD5oJJG8vnhbC8N/wyXiENErE4Rt/5sD9TXl2vpVIlABQszutn7vPl FptwUvjw==; Received: from j130084.upc-j.chello.nl ([24.132.130.84] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.96 #2 (Red Hat Linux)) id 1qvvUw-00H96Y-0x; Thu, 26 Oct 2023 08:13:46 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id EB2D8300473; Thu, 26 Oct 2023 10:13:45 +0200 (CEST) Date: Thu, 26 Oct 2023 10:13:45 +0200 From: Peter Zijlstra To: Boqun Feng Cc: rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, llvm@lists.linux.dev, Miguel Ojeda , Alex Gaynor , Wedson Almeida Filho , Gary Guo , =?iso-8859-1?Q?Bj=F6rn?= Roy Baron , Benno Lossin , Andreas Hindborg , Alice Ryhl , Alan Stern , Andrea Parri , Will Deacon , Nicholas Piggin , David Howells , Jade Alglave , Luc Maranget , "Paul E. McKenney" , Akira Yokosawa , Daniel Lustig , Joel Fernandes , Nathan Chancellor , Nick Desaulniers , Tom Rix , Alexander Viro , Christian Brauner , kent.overstreet@gmail.com, Greg Kroah-Hartman , elver@google.com, Matthew Wilcox , Dave Chinner , linux-fsdevel@vger.kernel.org, Linus Torvalds Subject: Re: [RFC] rust: types: Add read_once and write_once Message-ID: <20231026081345.GJ31411@noisy.programming.kicks-ass.net> References: <20231025195339.1431894-1-boqun.feng@gmail.com> Precedence: bulk X-Mailing-List: llvm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231025195339.1431894-1-boqun.feng@gmail.com> On Wed, Oct 25, 2023 at 12:53:39PM -0700, Boqun Feng wrote: > In theory, `read_volatile` and `write_volatile` in Rust can have UB in > case of the data races [1]. However, kernel uses volatiles to implement > READ_ONCE() and WRITE_ONCE(), and expects races on these marked accesses > don't cause UB. And they are proven to have a lot of usages in kernel. > > To close this gap, `read_once` and `write_once` are introduced, they > have the same semantics as `READ_ONCE` and `WRITE_ONCE` especially > regarding data races under the assumption that `read_volatile` and > `write_volatile` have the same behavior as a volatile pointer in C from > a compiler point of view. > > Longer term solution is to work with Rust language side for a better way > to implement `read_once` and `write_once`. But so far, it should be good > enough. So the whole READ_ONCE()/WRITE_ONCE() thing does two things we care about (AFAIR): - single-copy-atomicy; this can also be achieved using the C11 __atomic_load_n(.memorder=__ATOMIC_RELAXED) / __atomic_store_n(.memorder=__ATOMIC_RELAXED) thingies. - the ONCE thing; that is inhibits re-materialization, and here I'm not sure C11 atomics help, they might since re-reading an atomic is definitely dodgy -- after all it could've changed. Now, traditionally we've relied on the whole volatile thing simply because there was no C11, or our oldest compiler didn't do C11. But these days we actually *could*. Now, obviously C11 has issues vs LKMM, but perhaps the load/store semantics are near enough to be useful. (IIRC this also came up in the *very* long x86/percpu thread) So is there any distinction between the volatile load/store and the C11 atomic load/store that we care about and could not Rust use the atomic load/store to avoid their UB ?