Re: [PATCH 15/14] selftests: futex: Add tests for robust unlock within the critical section.

[Thomas Gleixner]

On Wed, May 27 2026 at 23:55, André Almeida wrote:
> Em 04/04/2026 06:39, Sebastian Andrzej Siewior escreveu:
>> +
>> +			} else if (state == STATE_IN_CS) {
>> +				/*
>> +				 * If the critical section has been entered then
>> +				 * the kernel has to unlock and clean list_op_pending.
>> +				 * On 32bit the pointer is just 32bit wide, the
>> +				 * upper 32bit are cleaned on 64bit.
>> +				 */
>> +				if (is_32bit)
>> +					rhead_val &= 0xffffffff;
>> +
>> +				ASSERT_EQ(rhead_val, 0);
>> +				ASSERT_EQ(lock_val, 0);
>> +			}
>
> It turns out that the test success I saw with my aarch64 implementation 
> was a false positive :/ There's no logic to verify if the code really 
> enters the critical section. If the code just jump over it, the test 
> never checks if lock_val and rhead_val are actually zeroed.
>
>> +
>> +			if (ptrace(PTRACE_SINGLESTEP, child, 0, 0))
>> +				err(1, "PTRACE_SINGLESTEP");
>
> After I fixed my code, the selftest got to an infinity loop (maybe we 
> should add max steps?). The single steps doesn't work for LL/SC locks, 
> like this one:
>
> retry:
> 	ldxr %w[val], %[lock]
> 	cmp %w[tid], %w[val]
> 	bne end
> 	stlxr %w[result], wzr, %[lock]
> 	cbnz %w[result], retry
> end:
>
>
> The single step with ptrace() causes a context switch that clear the 
> exclusive monitor[1], so store fails and the code branches to retry. We 
> need to jump straight to `cbnz %w[result], retry`. I tested to single 
> step with GDB, and it turns outs that it is smart enough to run the code 
> from ldxr to stlxr "atomically", to avoid messing with the exclusive 
> monitor and then it worked as expected.

That's why I put the labels into the ASM so that the test can set
breakpoints at the proper points and check whether the kernel/vdso did
the right thing. Single stepping is not really a good idea because you
can't test the interruption points, which matter correctly.

Thanks,

        tglx