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: >
  • Hotplug CPU. >
  • Scheduler and RCU. >
  • Tracing and RCU. > +
  • ------------------------------------^ > +Accesses to User Mamory and RCU. ---------------------^ >
  • Energy Efficiency. >
  • > Scheduling-Clock Interrupts and RCU. > @@ -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. > > +

    ----------------------------------^ > +Accesses to User Mamory and RCU

    ---------------------^ Are these issues especially notable for female programmers? :-) Alan