Re: [PATCH tip/core/rcu 01/14] rcu: Protect rcu_boost() lockless accesses with ACCESS_ONCE()

[Peter Zijlstra]

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/