[PATCH v16 6/8] nptl: Move the rseq area to the 'extra TLS' block

[Stefan Liebler]

On 16.01.25 16:45, Michael Jeanson wrote:
> On 2025-01-16 08:24, Stefan Liebler wrote: 
>> Hi,
>>
>> I've run kernel-next next-20250114 commit
>> dab2734f8e9ecba609d66d1dd087a392a7774c04 on s390x and get
>> FAIL: misc/tst-rseq-disable
>>
>> original exit status 1
>>
>> info: __rseq_size: 0
>>
>> info: __rseq_offset: -256
>>
>> info: __rseq_flags: 0
>>
>> info: getauxval (AT_RSEQ_FEATURE_SIZE): 28
>>
>> info: getauxval (AT_RSEQ_ALIGN): 32
>>
>> info: checking main thread
>>
>> ../sysdeps/unix/sysv/linux/tst-rseq-disable.c:90: numeric comparison failure
>>    left: -1 (0xffffffff); from: ret
>>   right: 0 (0x0); from: 0
>> info: checking main thread (2)
>> error: ../sysdeps/unix/sysv/linux/tst-rseq-disable.c:100: not true:
>> errno != EBUSY
>> info: checking new thread
>> ../sysdeps/unix/sysv/linux/tst-rseq-disable.c:90: numeric comparison failure
>>    left: -1 (0xffffffff); from: ret
>>   right: 0 (0x0); from: 0
>> info: checking subprocess
>> error: ../sysdeps/unix/sysv/linux/tst-rseq-disable.c:100: not true:
>> errno != EBUSY
>> error: 4 test failures
>>
>> Unregistration fails on main-thread with EBUSY.
>> Is this a known issue?
> 
> This test checks that the tunable 'glibc.pthread.rseq' actually disables
> the internal rseq registration. That part seems to work.
Yes, the first registration in "main thread" works.
> 
> The test then attempts to do its own rseq registration which in your
> case fails with EBUSY. This usually means there is already an active
> registration for the current thread which should not be the case.
The syscall with RSEQ_FLAG_UNREGISTER in "main thread" fails. I've
debugged to this syscall and it also fails with EBUSY.

> 
> Do you also see this failure on a released kernel?
No, I have not seen this fail before. Only on kernel-next (but no idea
when it started to fail there).

Any ideas how to track it down?
> 
> The only s390x system I have access to runs an old v6.1 kernel
> and the test succeeds on it.
> 
> 
>> Or does anybody see this FAIL on other architectures?
>>
>> Bye,
>> Stefan
>