All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.ibm.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: LKMM Maintainers -- Akira Yokosawa <akiyks@gmail.com>,
	Andrea Parri <andrea.parri@amarulasolutions.com>,
	Boqun Feng <boqun.feng@gmail.com>,
	Daniel Lustig <dlustig@nvidia.com>,
	David Howells <dhowells@redhat.com>,
	Jade Alglave <j.alglave@ucl.ac.uk>,
	Luc Maranget <luc.maranget@inria.fr>,
	Nicholas Piggin <npiggin@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Will Deacon <will.deacon@arm.com>,
	Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/3] tools: memory-model: Expand definition of barrier
Date: Thu, 20 Jun 2019 09:37:46 -0700	[thread overview]
Message-ID: <20190620163746.GS26519@linux.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1906201151210.1512-100000@iolanthe.rowland.org>

On Thu, Jun 20, 2019 at 11:55:36AM -0400, Alan Stern wrote:
> Commit 66be4e66a7f4 ("rcu: locking and unlocking need to always be at
> least barriers") added compiler barriers back into rcu_read_lock() and
> rcu_read_unlock().  Furthermore, srcu_read_lock() and
> srcu_read_unlock() have always contained compiler barriers.
> 
> The Linux Kernel Memory Model ought to know about these barriers.
> This patch adds them into the memory model.
> 
> Signed-off-by: Alan Stern <stern@rowland.harvard.edu>

And yes, much easier to understand this way, thank you!

I have queued them and they both diff equal to your previous patch and
give the expected results on the litmus-tests and github tests having
Result tags.

							Thanx, Paul

> ---
> 
> 
>  tools/memory-model/linux-kernel.cat |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> Index: usb-devel/tools/memory-model/linux-kernel.cat
> ===================================================================
> --- usb-devel.orig/tools/memory-model/linux-kernel.cat
> +++ usb-devel/tools/memory-model/linux-kernel.cat
> @@ -47,7 +47,8 @@ let strong-fence = mb | gp
>  let nonrw-fence = strong-fence | po-rel | acq-po
>  let fence = nonrw-fence | wmb | rmb
>  let barrier = fencerel(Barrier | Rmb | Wmb | Mb | Sync-rcu | Sync-srcu |
> -		Before-atomic | After-atomic | Acquire | Release) |
> +		Before-atomic | After-atomic | Acquire | Release |
> +		Rcu-lock | Rcu-unlock | Srcu-lock | Srcu-unlock) |
>  	(po ; [Release]) | ([Acquire] ; po)
>  
>  (**********************************)
> 

      reply	other threads:[~2019-06-20 16:38 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-20 15:55 [PATCH 1/3] tools: memory-model: Expand definition of barrier Alan Stern
2019-06-20 16:37 ` Paul E. McKenney [this message]

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=20190620163746.GS26519@linux.ibm.com \
    --to=paulmck@linux.ibm.com \
    --cc=akiyks@gmail.com \
    --cc=andrea.parri@amarulasolutions.com \
    --cc=boqun.feng@gmail.com \
    --cc=dhowells@redhat.com \
    --cc=dlustig@nvidia.com \
    --cc=j.alglave@ucl.ac.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luc.maranget@inria.fr \
    --cc=npiggin@gmail.com \
    --cc=peterz@infradead.org \
    --cc=stern@rowland.harvard.edu \
    --cc=will.deacon@arm.com \
    /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.