From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C456AC433F5 for ; Sat, 28 May 2022 13:57:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236214AbiE1N51 (ORCPT ); Sat, 28 May 2022 09:57:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48626 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236222AbiE1N5Y (ORCPT ); Sat, 28 May 2022 09:57:24 -0400 Received: from netrider.rowland.org (netrider.rowland.org [192.131.102.5]) by lindbergh.monkeyblade.net (Postfix) with SMTP id EAA6AA46F for ; Sat, 28 May 2022 06:57:19 -0700 (PDT) Received: (qmail 126261 invoked by uid 1000); 28 May 2022 09:57:19 -0400 Date: Sat, 28 May 2022 09:57:19 -0400 From: Alan Stern To: Akira Yokosawa Cc: "Paul E. McKenney" , "Michael S. Tsirkin" , Will Deacon , Peter Zijlstra , Boqun Feng , Andrea Parri , Nicholas Piggin , David Howells , Daniel Lustig , Joel Fernandes , Jonathan Corbet , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org Subject: Re: [RFC PATCH -lkmm] docs/memory-barriers: Fix inconsistent name of 'data dependency barrier' Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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" > Signed-off-by: Akira Yokosawa > Cc: "Paul E. McKenney" > Cc: Alan Stern > Cc: Will Deacon > Cc: Peter Zijlstra > Cc: Boqun Feng > Cc: Andrea Parri > Cc: Nicholas Piggin > Cc: David Howells > Cc: Daniel Lustig > Cc: Joel Fernandes > Cc: Jonathan Corbet > --- > 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@kernel.org/ > > 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