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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 18.08.2020 13:52, Julien Grall wrote:
> 
> 
> 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?

As long as both have weaknesses I'm afraid it's really a case-by-case
decision. If you're strictly after only the property that one has and
the other doesn't, the case is clear. In all other cases it'll need
weighing of the risks. No clear rules, I'm afraid.

Jan