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

[Michael Jeanson]

On 2025-01-16 11:26, Stefan Liebler wrote:
> 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.

Oh, I missed the failure on line 90. So re-reading the log, the main
thread registration works then fails to unregister, the second main thread
registration then fails with EBUSY since the previous registration is still
active. Same thing happens in the secondary thread.

> 
>>
>> 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?

Can you check what is the value of errno after the failed unregistration?

I'll have a look at linux-next and check if I can reprod on another
architecture.

>>
>> 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
>>
>