2024年9月29日 06:10，Alan Huang <mmpgour...@gmail.com> wrote：
>
> 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);
Or the following:
int **t = &b;
WRITE_ONCE(t, &b);
barrier();
return *b;
also works.
>
> also works.
>
> BTW, barrier_data(&b) generates more instructions than godbolt when build the
> kernel.
>
>>
>> Have fun,
>> jonas
