From: Alan Stern <stern@rowland.harvard.edu> To: "Paul E. McKenney" <paulmck@linux.ibm.com> Cc: Andrea Parri <andrea.parri@amarulasolutions.com>, Boqun Feng <boqun.feng@gmail.com>, Herbert Xu <herbert@gondor.apana.org.au>, Linus Torvalds <torvalds@linux-foundation.org>, Frederic Weisbecker <fweisbec@gmail.com>, Fengguang Wu <fengguang.wu@intel.com>, LKP <lkp@01.org>, LKML <linux-kernel@vger.kernel.org>, Netdev <netdev@vger.kernel.org>, "David S. Miller" <davem@davemloft.net>, Luc Maranget <luc.maranget@inria.fr>, Jade Alglave <j.alglave@ucl.ac.uk> Subject: Re: rcu_read_lock lost its compiler barrier Date: Sat, 8 Jun 2019 11:56:04 -0400 (EDT) [thread overview] Message-ID: <Pine.LNX.4.44L0.1906081153140.11124-100000@netrider.rowland.org> (raw) In-Reply-To: <20190608151943.GD28207@linux.ibm.com> On Sat, 8 Jun 2019, Paul E. McKenney wrote: > On Thu, Jun 06, 2019 at 10:19:43AM -0400, Alan Stern wrote: > > On Thu, 6 Jun 2019, Andrea Parri wrote: > > > > > This seems a sensible change to me: looking forward to seeing a patch, > > > on top of -rcu/dev, for further review and testing! > > > > > > We could also add (to LKMM) the barrier() for rcu_read_{lock,unlock}() > > > discussed in this thread (maybe once the RCU code and the informal doc > > > will have settled in such direction). > > > > Yes. Also for SRCU. That point had not escaped me. > > And it does seem pretty settled. There are quite a few examples where > there are normal accesses at either end of the RCU read-side critical > sections, for example, the one in the requirements diffs below. > > For SRCU, srcu_read_lock() and srcu_read_unlock() have implied compiler > barriers since 2006. ;-) > > Thanx, Paul > > ------------------------------------------------------------------------ > > diff --git a/Documentation/RCU/Design/Requirements/Requirements.html b/Documentation/RCU/Design/Requirements/Requirements.html > index 5a9238a2883c..080b39cc1dbb 100644 > --- a/Documentation/RCU/Design/Requirements/Requirements.html > +++ b/Documentation/RCU/Design/Requirements/Requirements.html > @@ -2129,6 +2129,8 @@ Some of the relevant points of interest are as follows: > <li> <a href="#Hotplug CPU">Hotplug CPU</a>. > <li> <a href="#Scheduler and RCU">Scheduler and RCU</a>. > <li> <a href="#Tracing and RCU">Tracing and RCU</a>. > +<li> <a href="#Accesses to User Mamory and RCU"> ------------------------------------^ > +Accesses to User Mamory and RCU</a>. ---------------------^ > <li> <a href="#Energy Efficiency">Energy Efficiency</a>. > <li> <a href="#Scheduling-Clock Interrupts and RCU"> > Scheduling-Clock Interrupts and RCU</a>. > @@ -2521,6 +2523,75 @@ cannot be used. > The tracing folks both located the requirement and provided the > needed fix, so this surprise requirement was relatively painless. > > +<h3><a name="Accesses to User Mamory and RCU"> ----------------------------------^ > +Accesses to User Mamory and RCU</a></h3> ---------------------^ Are these issues especially notable for female programmers? :-) Alan
WARNING: multiple messages have this Message-ID (diff)
From: Alan Stern <stern@rowland.harvard.edu> To: lkp@lists.01.org Subject: Re: rcu_read_lock lost its compiler barrier Date: Sat, 08 Jun 2019 11:56:04 -0400 [thread overview] Message-ID: <Pine.LNX.4.44L0.1906081153140.11124-100000@netrider.rowland.org> (raw) In-Reply-To: <20190608151943.GD28207@linux.ibm.com> [-- Attachment #1: Type: text/plain, Size: 2299 bytes --] On Sat, 8 Jun 2019, Paul E. McKenney wrote: > On Thu, Jun 06, 2019 at 10:19:43AM -0400, Alan Stern wrote: > > On Thu, 6 Jun 2019, Andrea Parri wrote: > > > > > This seems a sensible change to me: looking forward to seeing a patch, > > > on top of -rcu/dev, for further review and testing! > > > > > > We could also add (to LKMM) the barrier() for rcu_read_{lock,unlock}() > > > discussed in this thread (maybe once the RCU code and the informal doc > > > will have settled in such direction). > > > > Yes. Also for SRCU. That point had not escaped me. > > And it does seem pretty settled. There are quite a few examples where > there are normal accesses at either end of the RCU read-side critical > sections, for example, the one in the requirements diffs below. > > For SRCU, srcu_read_lock() and srcu_read_unlock() have implied compiler > barriers since 2006. ;-) > > Thanx, Paul > > ------------------------------------------------------------------------ > > diff --git a/Documentation/RCU/Design/Requirements/Requirements.html b/Documentation/RCU/Design/Requirements/Requirements.html > index 5a9238a2883c..080b39cc1dbb 100644 > --- a/Documentation/RCU/Design/Requirements/Requirements.html > +++ b/Documentation/RCU/Design/Requirements/Requirements.html > @@ -2129,6 +2129,8 @@ Some of the relevant points of interest are as follows: > <li> <a href="#Hotplug CPU">Hotplug CPU</a>. > <li> <a href="#Scheduler and RCU">Scheduler and RCU</a>. > <li> <a href="#Tracing and RCU">Tracing and RCU</a>. > +<li> <a href="#Accesses to User Mamory and RCU"> ------------------------------------^ > +Accesses to User Mamory and RCU</a>. ---------------------^ > <li> <a href="#Energy Efficiency">Energy Efficiency</a>. > <li> <a href="#Scheduling-Clock Interrupts and RCU"> > Scheduling-Clock Interrupts and RCU</a>. > @@ -2521,6 +2523,75 @@ cannot be used. > The tracing folks both located the requirement and provided the > needed fix, so this surprise requirement was relatively painless. > > +<h3><a name="Accesses to User Mamory and RCU"> ----------------------------------^ > +Accesses to User Mamory and RCU</a></h3> ---------------------^ Are these issues especially notable for female programmers? :-) Alan
next prev parent reply other threads:[~2019-06-08 15:56 UTC|newest] Thread overview: 99+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-09-10 0:57 [rcu] kernel BUG at include/linux/pagemap.h:149! Fengguang Wu 2015-09-10 0:57 ` Fengguang Wu 2015-09-10 10:25 ` Boqun Feng 2015-09-10 17:16 ` Paul E. McKenney 2015-09-10 17:16 ` Paul E. McKenney 2015-09-11 2:19 ` Boqun Feng [not found] ` <CAJzB8QG=1iZW3dQEie6ZSTLv8GZ3YSut0aL1VU7LLmiHQ1B1DQ@mail.gmail.com> 2015-09-11 21:59 ` Paul E. McKenney 2015-09-11 21:59 ` Paul E. McKenney 2015-09-12 5:46 ` Boqun Feng 2015-09-21 19:30 ` Frederic Weisbecker 2015-09-21 19:30 ` Frederic Weisbecker 2015-09-21 20:43 ` Paul E. McKenney 2015-09-21 20:43 ` Paul E. McKenney 2019-06-02 5:56 ` rcu_read_lock lost its compiler barrier Herbert Xu 2019-06-02 5:56 ` Herbert Xu 2019-06-02 20:54 ` Linus Torvalds 2019-06-02 20:54 ` Linus Torvalds 2019-06-03 2:46 ` Herbert Xu 2019-06-03 2:46 ` Herbert Xu 2019-06-03 3:47 ` Paul E. McKenney 2019-06-03 4:01 ` Herbert Xu 2019-06-03 4:01 ` Herbert Xu 2019-06-03 4:17 ` Herbert Xu 2019-06-03 4:17 ` Herbert Xu 2019-06-03 7:23 ` Paul E. McKenney 2019-06-03 8:42 ` Paul E. McKenney 2019-06-03 15:26 ` David Laight 2019-06-03 15:40 ` Linus Torvalds 2019-06-03 15:40 ` Linus Torvalds 2019-06-03 5:26 ` Herbert Xu 2019-06-03 5:26 ` Herbert Xu 2019-06-03 6:42 ` Boqun Feng 2019-06-03 6:42 ` Boqun Feng 2019-06-03 20:03 ` Paul E. McKenney 2019-06-04 14:44 ` Alan Stern 2019-06-04 14:44 ` Alan Stern 2019-06-04 16:04 ` Linus Torvalds 2019-06-04 16:04 ` Linus Torvalds 2019-06-04 17:00 ` Alan Stern 2019-06-04 17:00 ` Alan Stern 2019-06-04 17:29 ` Linus Torvalds 2019-06-04 17:29 ` Linus Torvalds 2019-06-07 14:09 ` inet: frags: Turn fqdir->dead into an int for old Alphas Herbert Xu 2019-06-07 14:09 ` Herbert Xu 2019-06-07 15:26 ` Eric Dumazet 2019-06-07 15:26 ` Eric Dumazet 2019-06-07 15:32 ` Herbert Xu 2019-06-07 15:32 ` Herbert Xu 2019-06-07 16:13 ` Eric Dumazet 2019-06-07 16:13 ` Eric Dumazet 2019-06-07 16:19 ` Linus Torvalds 2019-06-07 16:19 ` Linus Torvalds 2019-06-08 15:27 ` Paul E. McKenney 2019-06-08 17:42 ` Linus Torvalds 2019-06-08 17:42 ` Linus Torvalds 2019-06-08 17:50 ` Linus Torvalds 2019-06-08 17:50 ` Linus Torvalds 2019-06-08 18:50 ` Paul E. McKenney 2019-06-08 18:14 ` Paul E. McKenney 2019-06-06 4:51 ` rcu_read_lock lost its compiler barrier Herbert Xu 2019-06-06 4:51 ` Herbert Xu 2019-06-06 6:05 ` Paul E. McKenney 2019-06-06 6:14 ` Herbert Xu 2019-06-06 6:14 ` Herbert Xu 2019-06-06 9:06 ` Paul E. McKenney 2019-06-06 9:28 ` Herbert Xu 2019-06-06 9:28 ` Herbert Xu 2019-06-06 10:58 ` Paul E. McKenney 2019-06-06 13:38 ` Herbert Xu 2019-06-06 13:38 ` Herbert Xu 2019-06-06 13:48 ` Paul E. McKenney 2019-06-06 8:16 ` Andrea Parri 2019-06-06 14:19 ` Alan Stern 2019-06-06 14:19 ` Alan Stern 2019-06-08 15:19 ` Paul E. McKenney 2019-06-08 15:56 ` Alan Stern [this message] 2019-06-08 15:56 ` Alan Stern 2019-06-08 16:31 ` Paul E. McKenney 2019-06-03 9:35 ` Paul E. McKenney 2019-06-06 8:38 ` Andrea Parri 2019-06-06 9:32 ` Herbert Xu 2019-06-06 9:32 ` Herbert Xu 2019-06-03 0:06 ` Paul E. McKenney 2019-06-03 3:03 ` Herbert Xu 2019-06-03 3:03 ` Herbert Xu 2019-06-03 9:27 ` Paul E. McKenney 2019-06-03 15:55 ` Linus Torvalds 2019-06-03 15:55 ` Linus Torvalds 2019-06-03 16:07 ` Linus Torvalds 2019-06-03 16:07 ` Linus Torvalds 2019-06-03 19:53 ` Paul E. McKenney 2019-06-03 20:24 ` Linus Torvalds 2019-06-03 20:24 ` Linus Torvalds 2019-06-04 21:14 ` Paul E. McKenney 2019-06-05 2:21 ` Herbert Xu 2019-06-05 2:21 ` Herbert Xu 2019-06-05 3:30 ` Paul E. McKenney 2019-06-06 4:37 ` Herbert Xu 2019-06-06 4:37 ` Herbert Xu
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=Pine.LNX.4.44L0.1906081153140.11124-100000@netrider.rowland.org \ --to=stern@rowland.harvard.edu \ --cc=andrea.parri@amarulasolutions.com \ --cc=boqun.feng@gmail.com \ --cc=davem@davemloft.net \ --cc=fengguang.wu@intel.com \ --cc=fweisbec@gmail.com \ --cc=herbert@gondor.apana.org.au \ --cc=j.alglave@ucl.ac.uk \ --cc=linux-kernel@vger.kernel.org \ --cc=lkp@01.org \ --cc=luc.maranget@inria.fr \ --cc=netdev@vger.kernel.org \ --cc=paulmck@linux.ibm.com \ --cc=torvalds@linux-foundation.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: linkBe 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.