On Sat, May 28, 2022 at 01:15:30PM +0900, Akira Yokosawa wrote: > The term "data dependency barrier", which has been in > memory-barriers.txt ever since it was first authored by David Howells, > has become confusing due to the fact that in LKMM's explanations.txt > and elsewhere, "data dependency" is used mostly for load-to-store data > dependency. > > To prevent further confusions, do the following changes: > > - substitute "address-dependency barrier" for "data dependency barrier"; > - add note on the removal of kernel APIs for explicit address- > dependency barriers in kernel release v5.9; > - add note on the section title rename; > - use READ_ONCE_OLD() for READ_ONCE() of pre-4.15 (no address- > dependency implication) in code snippets; > - fix number of CPU memory barrier APIs; > - and a few more context adjustments. > > Note: Line break cleanups are deferred to a follow-up patch. > > Reported-by: "Michael S. Tsirkin" <mst@xxxxxxxxxx> > Signed-off-by: Akira Yokosawa <akiyks@xxxxxxxxx> > Cc: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxx> > Cc: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> > Cc: Will Deacon <will@xxxxxxxxxx> > Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx> > Cc: Boqun Feng <boqun.feng@xxxxxxxxx> > Cc: Andrea Parri <parri.andrea@xxxxxxxxx> > Cc: Nicholas Piggin <npiggin@xxxxxxxxx> > Cc: David Howells <dhowells@xxxxxxxxxx> > Cc: Daniel Lustig <dlustig@xxxxxxxxxx> > Cc: Joel Fernandes <joel@xxxxxxxxxxxxxxxxx> > Cc: Jonathan Corbet <corbet@xxxxxxx> > --- > This is a response to Michael's report back in last November [1]. > > [1]: "data dependency naming inconsistency": > https://lore.kernel.org/r/20211011064233-mutt-send-email-mst@xxxxxxxxxx/ > > In the thread, I suggested removing all the explanations of "data dependency > barriers", which Paul thought was reasonable. > > However, such removals would require rewriting the notoriously > hard-to-grasp document, which I'm not quite up to. > I have become more inclined to just substitute "address-dependency > barrier" for "data dependency barrier" considering the fact that > READ_ONCE() has an implicit memory barrier for Alpha. > > This RFC patch is the result of such an attempt. > > Note: I made a mistake in the thread above. Kernel APIs for explicit data > dependency barriers were removed in v5.9. > I confused the removal with the addition of the barrier to Alpha's > READ_ONCE() in v4.15. > > Any feedback is welcome! > > Thanks, Akira This looks great! Thanks a lot for working on it. The way memory-barriers.txt misuses "data dependency" to mean "address dependency" has bothered me for a long time; I'm very glad that it will finally get cleaned up. Alan
