All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>,
	Davidlohr Bueso <dave@stgolabs.net>,
	linux-kernel@vger.kernel.org, mingo@kernel.org,
	laijs@cn.fujitsu.com, dipankar@in.ibm.com,
	akpm@linux-foundation.org, mathieu.desnoyers@efficios.com,
	josh@joshtriplett.org, tglx@linutronix.de, rostedt@goodmis.org,
	dhowells@redhat.com, edumazet@google.com, dvhart@linux.intel.com,
	fweisbec@gmail.com, oleg@redhat.com,
	Pranith Kumar <bobby.prani@gmail.com>
Subject: Re: [PATCH tip/core/rcu 01/14] rcu: Protect rcu_boost() lockless accesses with ACCESS_ONCE()
Date: Mon, 12 Jan 2015 14:12:32 -0800	[thread overview]
Message-ID: <20150112221232.GG9719@linux.vnet.ibm.com> (raw)
In-Reply-To: <20150112085957.GA25256@twins.programming.kicks-ass.net>

On Mon, Jan 12, 2015 at 09:59:57AM +0100, Peter Zijlstra wrote:
> On Fri, Jan 09, 2015 at 10:58:50PM +0100, Christian Borntraeger wrote:
> > Am 09.01.2015 um 14:56 schrieb Peter Zijlstra:
> > > On Fri, Jan 09, 2015 at 05:49:54AM -0800, Paul E. McKenney wrote:
> > >>> That reminds me, I think the new conversion for stores will most likely
> > >>> introduce silly arg bugs:
> > >>>
> > >>> -       ACCESS_ONCE(a) = b;
> > >>> +       ASSIGN_ONCE(b, a);
> > >>
> > >> I was planning to do mine by hand for this sort of reason.
> > >>
> > >> Or are you thinking of something more subtle than the case where
> > >> "b" is an unparenthesized comma-separated expression?
> > > 
> > > I think he's revering to the wrong way around-ness of the thing.
> > > 
> > > Its a bit of a mixed bag on assignments, but for instance
> > > rcu_assign_pointer() takes them the right way around, as does
> > > atomic_set().
> > > 
> > > So yes, I think the ASSIGN_ONCE() thing got the arguments the wrong way
> > > around.
> > > 
> > > We could maybe still change it, before its in too long ?
> > 
> > Linus initial proposal was inspired by put_user model which is (val,
> > ptr) and I took that. 
> 
> Yeah, like I said, its a bit of a mixed bag. We've got plenty examples
> of the wrong way around.
> 
> > As my focus was on avoiding the volatile bug,
> > all my current conversions are READ_ONCE as no potential ASSIGN_ONCE
> > user was done on a non-scalar type, so I have no first hand
> > experience. 
> 
> So the implication there is that we'd preserve ACCESS_ONCE() for use on
> scalar types. I don't think we should do that, I think we should just
> en-mass convert to {READ,WRITE}/{LOAD,STORE}_ONCE() and kill off
> ACCESS_ONCE().

Yep.  For one thing, the proposed replacements work much better with
C11 than does ACCESS_ONCE().

> > I am fine with changing that, though, both ways have pros
> > and cons. Last time I checked in Linus tree there was no ASSIGN_ONCE
> > user.
> 
> Right, so Davidlohr just introduced a few in my tree :-), which is how I
> came to know we even had this stuff..
> 
> > When we talk about changing the parameters it might make sense to also
> > think about some comments from George Spelvin and consider a rename to
> > WRITE_ONCE or STORE_ONCE (READ_ONCE --> LOAD_ONCE). 
> 
> I'd be OK with that.
> 
> > Unfortunately
> > there doesnt seem to be a variant that is fool proof (in the sense of
> > Rustys guideline that a good interface cannot be used wrong). So any
> > proposal in that regard would be very welcome.
> 
> If you want fool proof, I think we should discard C ;-) Then again, I've
> yet to see a programming language that would not let a human make a
> proper idiot out of himself.

Limit NR_CPUS to zero!  It is the only way!!!

						Thanx, Paul


  reply	other threads:[~2015-01-12 22:12 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-07 17:32 [PATCH tip/core/rcu 0/14] Preemptible-RCU updates for 3.20 Paul E. McKenney
2015-01-07 17:32 ` [PATCH tip/core/rcu 01/14] rcu: Protect rcu_boost() lockless accesses with ACCESS_ONCE() Paul E. McKenney
2015-01-07 17:32   ` [PATCH tip/core/rcu 02/14] rcu: Rename "empty" to "empty_norm" in preparation for boost rework Paul E. McKenney
2015-01-07 17:32   ` [PATCH tip/core/rcu 03/14] rcu: Abstract rcu_cleanup_dead_rnp() from rcu_cleanup_dead_cpu() Paul E. McKenney
2015-01-07 17:32   ` [PATCH tip/core/rcu 04/14] rcu: Make rcu_read_unlock_special() propagate ->qsmaskinit bit clearing Paul E. McKenney
2015-01-07 17:32   ` [PATCH tip/core/rcu 05/14] rcu: Don't migrate blocked tasks even if all corresponding CPUs offline Paul E. McKenney
2015-01-07 17:32   ` [PATCH tip/core/rcu 06/14] rcu: Shorten irq-disable region in rcu_cleanup_dead_cpu() Paul E. McKenney
2015-01-07 17:32   ` [PATCH tip/core/rcu 07/14] rcu: Make use of rcu_preempt_has_tasks() Paul E. McKenney
2015-01-07 17:32   ` [PATCH tip/core/rcu 08/14] rcu: Don't spawn rcub kthreads on root rcu_node structure Paul E. McKenney
2015-01-07 17:32   ` [PATCH tip/core/rcu 09/14] rcu: Don't initiate RCU priority boosting on root rcu_node Paul E. McKenney
2015-01-07 17:32   ` [PATCH tip/core/rcu 10/14] rcu: Don't bother affinitying rcub kthreads away from offline CPUs Paul E. McKenney
2015-01-07 17:32   ` [PATCH tip/core/rcu 11/14] rcu: Note quiescent state when CPU goes offline Paul E. McKenney
2015-01-07 17:32   ` [PATCH tip/core/rcu 12/14] rcu: Revert "Allow post-unlock reference for rt_mutex" to avoid priority-inversion Paul E. McKenney
2015-01-07 17:32   ` [PATCH tip/core/rcu 13/14] rcu: Don't scan root rcu_node structure for stalled tasks Paul E. McKenney
2015-01-07 17:32   ` [PATCH tip/core/rcu 14/14] rcu: Remove redundant callback-list initialization Paul E. McKenney
2015-01-08  9:41   ` [PATCH tip/core/rcu 01/14] rcu: Protect rcu_boost() lockless accesses with ACCESS_ONCE() Peter Zijlstra
2015-01-08 15:22     ` Paul E. McKenney
2015-01-09  6:41       ` Davidlohr Bueso
2015-01-09 13:49         ` Paul E. McKenney
2015-01-09 13:56           ` Peter Zijlstra
2015-01-09 14:07             ` Paul E. McKenney
2015-01-09 16:53               ` Mathieu Desnoyers
2015-01-09 21:58             ` Christian Borntraeger
2015-01-10  0:27               ` Davidlohr Bueso
2015-01-12  8:59               ` Peter Zijlstra
2015-01-12 22:12                 ` Paul E. McKenney [this message]
2015-01-13  8:18                   ` Christian Borntraeger
2015-01-13  9:29                     ` Peter Zijlstra
2015-01-13 17:47                     ` Paul E. McKenney
2015-01-13 19:12                     ` Davidlohr Bueso

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=20150112221232.GG9719@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=bobby.prani@gmail.com \
    --cc=borntraeger@de.ibm.com \
    --cc=dave@stgolabs.net \
    --cc=dhowells@redhat.com \
    --cc=dipankar@in.ibm.com \
    --cc=dvhart@linux.intel.com \
    --cc=edumazet@google.com \
    --cc=fweisbec@gmail.com \
    --cc=josh@joshtriplett.org \
    --cc=laijs@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@kernel.org \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    /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.