Re: [PATCH bpf-next v9 1/6] locking/local_lock: Introduce localtry_lock_t

[Vlastimil Babka <vbabka@suse.cz>]

On 3/14/25 22:05, Alexei Starovoitov wrote:
> On Wed, Mar 12, 2025 at 1:29 AM Vlastimil Babka <vbabka@suse.cz> wrote:
> 
> That's correct.
> 
>> An if we e.g. have a pointer to memcg_stock_pcp through which we access the
>> stock_lock an the other (protected) fields and that pointer doesn't change
>> between that, I imagine gcc can reliably determine these can't alias?
> 
> Though my last gcc commit was very long ago here is a simple example
> where compiler can reorder/combine stores:
> struct s {
>    short a, b;
> } *p;
> p->a = 1;
> p->b = 2;
> The compiler can keep them as-is, combine or reorder even with
> -fno-strict-aliasing, because it can determine that a and b don't alias.
> 
> But after re-reading gcc doc on volatiles again it's clear that
> extra barriers are not necessary.
> The main part:
> "The minimum requirement is that at a sequence point all previous
> accesses to volatile objects have stabilized"
> 
> So anything after WRITE_ONCE(lt->acquired, 1); will not be hoisted up
> and that's what we care about here.

OK, is there similar guarantee for the unlock side? No write will be moved
after WRITE_ONCE(lt->acquired, 0); there?