2024年9月28日 06:18,Jonas Oberhauser <jonas.oberhau...@huaweicloud.com> wrote:
> 
> 
> 
> Am 9/27/2024 um 10:10 PM schrieb Mathieu Desnoyers:
>> On 2024-09-27 21:23, Jonas Oberhauser wrote:
>> [...]
>>> That idea seems to be confirmed by this (atrocious, not to be copied!) 
>>> example:
>>> 
>>> int fct_escape_address_of_b(void)
>>> {
>>>      int *a, *b;
>>> 
>>>      do {
>>>          a = READ_ONCE(p);
>>>          asm volatile ("" : : : "memory");
>>>          b = READ_ONCE(p);
>>>      } while (a != b);
>>> 
>>>      // really really hide b
>>>      int **p = &b;
>>>      OPTIMIZER_HIDE_VAR(p);
>>> 
>>>      asm volatile ("" : : : "memory");
>>>      return *b;
>>> }
>>> 
>>> This also does not generate any additional instructions, unlike just using 
>>> OPTIMIZER_HIDE_VAR(b).
>>> 
>>> What is the advantage of defining OPTIMIZE_HIDE_VAR the way it currently 
>>> works instead of like above?
>> Did you try it on godbolt.org ? Does it have the intended effect ?
> 
> I certainly did try and certainly read it as having the intended effect, 
> otherwise I wouldn't have written that it seems confirmed.
> 
> However, just because my eyes read it doesn't mean that's what happened, and 
> even if it happened doesn't mean that it is guaranteed to happen.
> 
>> By the looks of it, you're just creating another version of @b called
>> "p", which is then never used and would be discarded by further
>> optimization. >
>> I'm unsure what you are trying to achieve here.
> 
> Simply put I'm trying to let the compiler think that I leaked the address of 
> b. After that, the memory barrier should let it think that the b after the 
> memory barrier might not be the same as the one before it (which was equal to 
> a), forcing it to read from b.
> 
> However, I suppose on second thought that that might not be enough, because 
> the compiler could still simply do b = a right after exiting the while loop.
> 
> And that is true no matter what we put behind the while loop or before the 
> condition, as long as the condition compares a and b, right after it the 
> compiler can do b = a. Just took me a while to see :))
> 
> I'm not sure why gcc does the b=a with the normal OPTIMIZER_HIDE_VAR but (as 
> far as I read the code) doesn't do it with the above. Maybe just a weird 
> corner case...

Let the p to be a static variable out of the function will make a difference.

Or the following:
        
        int **p = &b;
        barrier_data(p);

also works.

BTW, barrier_data(&b) generates more instructions than godbolt when build the 
kernel.

> 
> Have fun,
>  jonas
> 
> 


Reply via email to