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
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).