[PATCH v12 01/17] nptl: Add rseq auxvals

[Michael Jeanson]

On 2024-08-15 13:54, Florian Weimer wrote:
> * Michael Jeanson:
> 
>> On 2024-08-06 09:32, Michael Jeanson wrote:
>>> Before the removal of _dl_rseq_feature_size there was no behavior
>>> change introduced until "Move the rseq area to the 'extra TLS'
>>> block" which is where _rseq_size is set to 0 on failure. I agree it
>>> would make more sense to have it in this patch, I'll queue this
>>> change for the next round.
>>
>> I was wondering if this patch with the code to set _rseq_size to zero
>> on registration failure, plus an additional modification to cap the
>> _rseq_size to 32 (the size of the rseq area in the struct pthread)
>> could be backported to 2.40 and earlier? It would give application
>> code access to the 'node_id' and 'mm_cid' fields without introducing
>> the whole 'extra tls' stuff.
>>
>> Thoughts?
> 
> I thought about this some more.  I think we should also increase the
> reservation inside struct pthread beyond 32 bytes if we do this, so that
> we avoid the __rseq_size == 32 ambiguity.  It currently doesn't break
> the GLIBC_PRIVATE ABI because rseq_area is at the end of struct pthread.
> (As long as we assume that ld.so gets updated before libc.so because it
> comes first in lexicographic order.)

So the plan for 2.40 would look something like this?

- Increase the size of the rseq area in 'struct pthread' to 64 bytes or more?
- Set __rseq_size from AT_RSEQ_FEATURE_SIZE with a min of 20 and max of 64

The resulting __rseq_size for different kernels:

- kernel < 6.3 (AT_RSEQ_FEATURE_SIZE == 0) : __rseq_size == 20
   - Same behavior as current 2.40

- kernel >= 6.3 (AT_RSEQ_FEATURE_SIZE == 28) : __rseq_size == 28
   - Exposes 'node_id' and 'mm_cid' to userspace

- future unreleased kernel (AT_RSEQ_FEATURE_SIZE == 32) : __rseq_size == 32
   - We expect such a kernel to never exist, but would technically work

- future unreleased kernel (AT_RSEQ_FEATURE_SIZE == 36) : __rseq_size == 36
   - Exposes future fields to userspace

- future unreleased kernel (AT_RSEQ_FEATURE_SIZE > 64) : __rseq_size == 0
   - Attempting registration with a kernel that has a feature size bigger than
     our rseq area would result in a failed registration. We don't deal with
     the planned compat mode of 32 bytes.

Does that align with what you have in mind?

Thanks,

Michael