Re: [musl] Illegal killlock skipping when transitioning to single-threaded state

[Alexey Izbyshev <izbyshev@ispras.ru>]

On 2022-10-04 11:31, Szabolcs Nagy wrote:
> * Alexey Izbyshev <izbyshev@ispras.ru> [2022-10-04 08:16:16 +0300]:
> 
>> On 2022-10-04 00:27, Szabolcs Nagy wrote:
>> > * Szabolcs Nagy <nsz@port70.net> [2022-10-03 15:26:15 +0200]:
>> > i think i was wrong and you are right.
>> >
>> > so with your suggested swap of UNLOCK(killlock) and need_locks=-1 and
>> > starting with 'something == 0' the exiting E and remaining R threads:
>> >
>> > E:something=1      // protected by killlock
>> > E:UNLOCK(killlock)
>> > E:need_locks=-1
>> >
>> > R:LOCK(unrelated)  // reads need_locks == -1
>> > R:need_locks=0
>> > R:UNLOCK(unrelated)
>> > R:LOCK(killlock)   // does not lock
>> > R:read something   // can it be 0 ?
>> >
>> > and here something can be 0 (ie. not protected by killlock) on aarch64
>> > because
>> >
>> > T1
>> > 	something=1
>> > 	ldaxr ... killlock
>> > 	stlxr ... killlock
>> > 	need_locks=-1
>> >
>> > T2
>> > 	x=need_locks
>> > 	ldaxr ... unrelated
>> > 	stlxr ... unrelated
>> > 	y=something
>> >
>> > can end with x==-1 and y==0.
>> >
>> Yes, overall this matches my understanding. However, your UNLOCK 
>> expansion
>> (in T1/T2) omits the branch instruction between stlxr and the 
>> following
>> store, and, as I mentioned, I'm not sufficiently knowledgeable to 
>> understand
>> the effects of this branch on the order of visibility of "stlxr 
>> killlock"
>> (and preceding stores) and "need_locks=-1".
> 
> i don't know the answer, but i think in musl we don't want to rely on
> control dependcies in the architectural memory model anyway (in some
> cases the compiler can break it and it's hard to reason about).
> 
I agree. The answer appears to be that the reordering can occur even in 
the presence of the branch instruction[1], though I haven't confirmed it 
with tools that show valid executions yet.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697#c23

Thanks,
Alexey