Re: [PATCH] xen/x86: irq: Avoid a TOCTOU race in pirq_spin_lock_irq_desc()

[Julien Grall <julien@xxxxxxx>]

On 18/08/2020 12:27, Jan Beulich wrote:
> On 18.08.2020 11:12, Julien Grall wrote:
> > > As pointed
> > > out before, ACCESS_ONCE() and {read,write}_atomic() serve slightly
> > > different purposes, and so far it looks like all of us are lacking ideas
> > > on how to construct something that catches all cases by one single approach.
> > I am guessing you are referring to [1], right?
> >
> > If you read the documentation of READ_ONCE()/WRITE_ONCE(), they are meant to be 
> > atomic in some cases. The cases are exactly the same as {read, write}_atomic().
> >
> > I will ask the same thing as I asked to Roger. If Linux can rely on it, why 
> > can't we?
> That's not the way I'd like to see arguments go here: If Linux has
> something suitable, I'm fine with us using it. But we ought to be
> permitted to question whether what we inherit is indeed fit for
> purpose, and afaict there is at least one gap to be filled. In no
> case should we blindly pull in things from Linux and then assume
> that simply by doing so all is well.
I don't think any of us here are compilers guru, so I would tend to rely 
on Linux memory work. After all their code received much more attention. 
But sure we can question everything they have been doing.
To me the expected semantics (/!\ I am not referring to the 
implementation) for all the helpers are the same. But you seem to 
disagree on that.
I read the thread again and I couldn't find any explanation how a 
developper could chose between ACCESS_ONCE() and {read, write}_atomic().
Can you outline how one would decide?

Cheers,

--
Julien Grall