All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.ibm.com>
To: Andrea Parri <andrea.parri@amarulasolutions.com>
Cc: Alan Stern <stern@rowland.harvard.edu>,
	LKMM Maintainers -- Akira Yokosawa <akiyks@gmail.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 0/3] tools/memory-model: Add SRCU support
Date: Tue, 27 Nov 2018 09:17:46 -0800	[thread overview]
Message-ID: <20181127171746.GP4170@linux.ibm.com> (raw)
In-Reply-To: <20181127002642.GA4087@andrea>

On Tue, Nov 27, 2018 at 01:26:42AM +0100, Andrea Parri wrote:
> > commit 72f61917f12236514a70017d1ebafb9b8d34a9b6
> > Author: Paul E. McKenney <paulmck@linux.ibm.com>
> > Date:   Mon Nov 26 14:26:43 2018 -0800
> > 
> >     tools/memory-model: Update README for addition of SRCU
> >     
> >     This commit updates the section on LKMM limitations to no longer say
> >     that SRCU is not modeled, but instead describe how LKMM's modeling of
> >     SRCU departs from the Linux-kernel implementation.
> >     
> >     TL;DR:  There is no known valid use case that cares about the Linux
> >     kernel's ability to have partially overlapping SRCU read-side critical
> >     sections.
> >     
> >     Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
> 
> Indeed!,
> 
> Acked-by: Andrea Parri <andrea.parri@amarulasolutions.com>

Thank you, applied!

I moved this commit and Alan's three SRCU commits to the branch destined
for the upcoming merge window.

							Thanx, Paul

>   Andrea
> 
> 
> > 
> > diff --git a/tools/memory-model/README b/tools/memory-model/README
> > index 0f2c366518c6..9d7d4f23503f 100644
> > --- a/tools/memory-model/README
> > +++ b/tools/memory-model/README
> > @@ -221,8 +221,29 @@ The Linux-kernel memory model has the following limitations:
> >  		additional call_rcu() process to the site of the
> >  		emulated rcu-barrier().
> >  
> > -	e.	Sleepable RCU (SRCU) is not modeled.  It can be
> > -		emulated, but perhaps not simply.
> > +	e.	Although sleepable RCU (SRCU) is now modeled, there
> > +		are some subtle differences between its semantics and
> > +		those in the Linux kernel.  For example, the kernel
> > +		might interpret the following sequence as two partially
> > +		overlapping SRCU read-side critical sections:
> > +
> > +			 1  r1 = srcu_read_lock(&my_srcu);
> > +			 2  do_something_1();
> > +			 3  r2 = srcu_read_lock(&my_srcu);
> > +			 4  do_something_2();
> > +			 5  srcu_read_unlock(&my_srcu, r1);
> > +			 6  do_something_3();
> > +			 7  srcu_read_unlock(&my_srcu, r2);
> > +
> > +		In contrast, LKMM will interpret this as a nested pair of
> > +		SRCU read-side critical sections, with the outer critical
> > +		section spanning lines 1-7 and the inner critical section
> > +		spanning lines 3-5.
> > +
> > +		This difference would be more of a concern had anyone
> > +		identified a reasonable use case for partially overlapping
> > +		SRCU read-side critical sections.  For more information,
> > +		please see: https://paulmck.livejournal.com/40593.html
> >  
> >  	f.	Reader-writer locking is not modeled.  It can be
> >  		emulated in litmus tests using atomic read-modify-write
> > 
> 


  reply	other threads:[~2018-11-27 17:17 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-15 16:19 [PATCH 0/3] tools/memory-model: Add SRCU support Alan Stern
2018-11-16  6:43 ` Paul E. McKenney
2018-11-16 15:34   ` Alan Stern
2018-11-19 12:01 ` Andrea Parri
2018-11-26 22:35   ` Paul E. McKenney
2018-11-27  0:26     ` Andrea Parri
2018-11-27 17:17       ` Paul E. McKenney [this message]
2018-11-27 22:34         ` Akira Yokosawa
2018-11-28  0:08           ` 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=20181127171746.GP4170@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.