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

[Michael Jeanson]

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.

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.

Do you also see this failure on a released kernel?

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