[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZTndmXEBf37G84X-@Boquns-Mac-mini.home>
Date: Wed, 25 Oct 2023 20:31:37 -0700
From: Boqun Feng <boqun.feng@...il.com>
To: Benno Lossin <benno.lossin@...ton.me>
Cc: rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arch@...r.kernel.org, llvm@...ts.linux.dev,
Miguel Ojeda <ojeda@...nel.org>,
Alex Gaynor <alex.gaynor@...il.com>,
Wedson Almeida Filho <wedsonaf@...il.com>,
Gary Guo <gary@...yguo.net>,
Björn Roy Baron <bjorn3_gh@...tonmail.com>,
Andreas Hindborg <a.hindborg@...sung.com>,
Alice Ryhl <aliceryhl@...gle.com>,
Alan Stern <stern@...land.harvard.edu>,
Andrea Parri <parri.andrea@...il.com>,
Will Deacon <will@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Nicholas Piggin <npiggin@...il.com>,
David Howells <dhowells@...hat.com>,
Jade Alglave <j.alglave@....ac.uk>,
Luc Maranget <luc.maranget@...ia.fr>,
"Paul E. McKenney" <paulmck@...nel.org>,
Akira Yokosawa <akiyks@...il.com>,
Daniel Lustig <dlustig@...dia.com>,
Joel Fernandes <joel@...lfernandes.org>,
Nathan Chancellor <nathan@...nel.org>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Tom Rix <trix@...hat.com>,
Alexander Viro <viro@...iv.linux.org.uk>,
Christian Brauner <brauner@...nel.org>,
kent.overstreet@...il.com,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
elver@...gle.com, Matthew Wilcox <willy@...radead.org>,
Dave Chinner <david@...morbit.com>,
linux-fsdevel@...r.kernel.org
Subject: Re: [RFC] rust: types: Add read_once and write_once
On Wed, Oct 25, 2023 at 04:02:45PM -0700, Boqun Feng wrote:
[...]
> > > +/// The counter part of C `READ_ONCE()`.
> > > +///
> > > +/// The semantics is exactly the same as `READ_ONCE()`, especially when used for intentional data
> > > +/// races.
> >
> > It would be great if these semantics are either linked or spelled out
> > here. Ideally both.
> >
>
> Actually I haven't found any document about `READ_ONCE()` races with
> writes is not UB: we do have document saying `READ_ONCE()` will disable
> KCSAN checks, but no document says (explicitly) that it's not a UB.
>
Apparently I wasn't carefully reading the doc, in
tools/memory-model/Documentation/explanation.txt, there is:
In technical terms, the compiler is allowed to assume that when the
program executes, there will not be any data races. A "data race"
occurs when there are two memory accesses such that:
1. they access the same location,
2. at least one of them is a store,
3. at least one of them is plain,
4. they occur on different CPUs (or in different threads on the
same CPU), and
5. they execute concurrently.
the #3 limits that in LKMM, data races cannot happen if both accesses
are marked (i.e. not plain).
Thank Paul for bringing this to me, and I will update this accordingly
in the next version.
Regards,
Boqun
> > > +///
> > > +/// # Safety
> > > +///
> > > +/// * `src` must be valid for reads.
> > > +/// * `src` must be properly aligned.
> > > +/// * `src` must point to a properly initialized value of value `T`.
> > > +#[inline(always)]
> > > +pub unsafe fn read_once<T: Copy>(src: *const T) -> T {
> >
> > Why only `T: Copy`?
> >
[...]
Powered by blists - more mailing lists