Messages in this thread | | | Date | Mon, 12 Jan 2015 09:59:57 +0100 | From | Peter Zijlstra <> | Subject | Re: [PATCH tip/core/rcu 01/14] rcu: Protect rcu_boost() lockless accesses with ACCESS_ONCE() |
| |
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().
> 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.
| |