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

Stefan Liebler stli@linux.ibm.com
Thu Jan 16 13:24:27 GMT 2025


On 10.01.25 20:39, Florian Weimer wrote:
> * Michael Jeanson:
> 
>> +#if TLS_TCB_AT_TP
>> +  /* The rseq area block should come before the thread pointer and be at least
>> +     32 bytes. */
>> +  TEST_VERIFY (__rseq_offset <= -RSEQ_AREA_SIZE_INITIAL);
>> +
>> +  /* The rseq area block should come before TLS variables.  */
>> +  TEST_VERIFY ((intptr_t) rseq_abi < (intptr_t) &tls_var);
>> +#elif TLS_DTV_AT_TP
>> +  /* The rseq area block should come after the TCB, add the TLS block offset to
>> +     the rseq offset to get a value relative to the TCB and test that it's
>> +     non-negative.  */
>> +  TEST_VERIFY (__rseq_offset + TLS_TP_OFFSET >= 0);
>> +
>> +  /* The rseq area block should come after TLS variables.  */
>> +  TEST_VERIFY ((intptr_t) rseq_abi > (intptr_t) &tls_var);
>> +#else
>> +# error "Either TLS_TCB_AT_TP or TLS_DTV_AT_TP must be defined"
>> +#endif
> 
> Looks good now.  Rest is okay as well.
> 
> Reviewed-by: Florian Weimer <fweimer@redhat.com>
> 
> Thanks,
> Florian
> 

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?
Or does anybody see this FAIL on other architectures?

Bye,
Stefan


More information about the Libc-alpha mailing list