All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea Parri <parri.andrea@gmail.com>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
	linux-doc@vger.kernel.org, Alan Stern <stern@rowland.harvard.edu>,
	Will Deacon <will@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Nicholas Piggin <npiggin@gmail.com>,
	David Howells <dhowells@redhat.com>,
	Jade Alglave <j.alglave@ucl.ac.uk>,
	Luc Maranget <luc.maranget@inria.fr>,
	Akira Yokosawa <akiyks@gmail.com>,
	Daniel Lustig <dlustig@nvidia.com>,
	Joel Fernandes <joel@joelfernandes.org>,
	Jonathan Corbet <corbet@lwn.net>
Subject: Re: [PATCH memory-model] docs: memory-barriers: Add note on compiler transformation and address deps
Date: Fri, 6 Oct 2023 16:24:38 +0200	[thread overview]
Message-ID: <ZSAYplkpVlmcL1bb@andrea> (raw)
In-Reply-To: <ceaeba0a-fc30-4635-802a-668c859a58b2@paulmck-laptop>

On Thu, Oct 05, 2023 at 09:53:12AM -0700, Paul E. McKenney wrote:
> The compiler has the ability to cause misordering by destroying
> address-dependency barriers if comparison operations are used. Add a
> note about this to memory-barriers.txt in the beginning of both the
> historical address-dependency sections and point to rcu-dereference.rst
> for more information.
> 
> Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>

Reviewed-by: Andrea Parri <parri.andrea@gmail.com>

Thanks,
  Andrea


> diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
> index 06e14efd8662..d414e145f912 100644
> --- a/Documentation/memory-barriers.txt
> +++ b/Documentation/memory-barriers.txt
> @@ -396,6 +396,10 @@ Memory barriers come in four basic varieties:
>  
>  
>   (2) Address-dependency barriers (historical).
> +     [!] This section is marked as HISTORICAL: For more up-to-date
> +     information, including how compiler transformations related to pointer
> +     comparisons can sometimes cause problems, see
> +     Documentation/RCU/rcu_dereference.rst.
>  
>       An address-dependency barrier is a weaker form of read barrier.  In the
>       case where two loads are performed such that the second depends on the
> @@ -556,6 +560,9 @@ There are certain things that the Linux kernel memory barriers do not guarantee:
>  
>  ADDRESS-DEPENDENCY BARRIERS (HISTORICAL)
>  ----------------------------------------
> +[!] This section is marked as HISTORICAL: For more up-to-date information,
> +including how compiler transformations related to pointer comparisons can
> +sometimes cause problems, see Documentation/RCU/rcu_dereference.rst.
>  
>  As of v4.15 of the Linux kernel, an smp_mb() was added to READ_ONCE() for
>  DEC Alpha, which means that about the only people who need to pay attention

  reply	other threads:[~2023-10-06 14:24 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-05 16:53 [PATCH memory-model] docs: memory-barriers: Add note on compiler transformation and address deps Paul E. McKenney
2023-10-06 14:24 ` Andrea Parri [this message]
2023-10-06 15:49   ` Paul E. McKenney
2023-10-06 16:39 ` Jonas Oberhauser
2023-10-18 10:11   ` Jonas Oberhauser
2023-10-19 16:39     ` Paul E. McKenney
2023-10-20  9:29       ` Jonas Oberhauser
2023-10-20 13:57         ` Paul E. McKenney
2023-10-20 15:24           ` Akira Yokosawa
2023-10-20 16:13             ` Jonas Oberhauser
2023-10-20 17:56               ` Paul E. McKenney
2023-10-21 13:45                 ` Jonas Oberhauser
2023-10-21 15:31                   ` Paul E. McKenney
2023-10-20 16:00           ` Jonas Oberhauser
2023-10-20 18:13             ` Paul E. McKenney
2023-10-21 13:36               ` Jonas Oberhauser
2023-10-21 15:10                 ` Paul E. McKenney
2023-10-21 16:03                   ` Alan Stern
2023-10-21 20:07                     ` Paul E. McKenney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZSAYplkpVlmcL1bb@andrea \
    --to=parri.andrea@gmail.com \
    --cc=akiyks@gmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=corbet@lwn.net \
    --cc=dhowells@redhat.com \
    --cc=dlustig@nvidia.com \
    --cc=j.alglave@ucl.ac.uk \
    --cc=joel@joelfernandes.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luc.maranget@inria.fr \
    --cc=npiggin@gmail.com \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=stern@rowland.harvard.edu \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.