Re: [RFC PATCH v2 1/2] rseq: extend struct rseq with numa node id

[Mathieu Desnoyers <mathieu.desnoyers@efficios.com>]

----- On Feb 1, 2022, at 2:28 PM, Peter Oskolkov posk@posk.io wrote:

Hi Peter,

[...]

>>  TRACE_EVENT(rseq_ip_fixup,
>> diff --git a/include/uapi/linux/rseq.h b/include/uapi/linux/rseq.h
>> index 77ee207623a9..386c25b5bbdb 100644
>> --- a/include/uapi/linux/rseq.h
>> +++ b/include/uapi/linux/rseq.h
>> @@ -130,6 +130,30 @@ struct rseq {
>>          *     this thread.
>>          */
>>         __u32 flags;
>> +
>> +       __u32 padding1[3];
> 
> I don't fully understand why this padding is needed here. The comment
> below sounds like there was something in "the original rseq API", but
> was later removed, as this patch clearly adds padding after flags, but
> even the first rseq patch had 'flags' as the last field in struct
> rseq...

The struct rseq has an explicit alignment attribute of 32 bytes, which means
that even though we populate 20 bytes up to (including) the flags field, there is
implicitly 12 bytes or padding at the end of that structure. The size of the rseq_len
argument expected by the rseq system call since 4.18 is sizeof(struct rseq), which is
32 bytes (including the implicit padding).

So if we want to use the structure size as a way to indicate available features,
we need to explicitly express the padding field (12 bytes), and start using offsetofend()
on the following fields to allow per-field feature granularity without requiring
additional padding in the future.

If in the original rseq implementation we would have expected offsetofend() of the
flags fields as rseq_len, then we would not need those silly 12 bytes of padding,
but here we are.

> 
> Also have you considered adding an explicit 'version' field, or
> something more sophisticated than 'len'? I remember about a year ago
> you had an rfc patch(set) addressing rseq versioning, but I don't
> think it got merged? You had some concerns about using 'len' then...

It's vague in my memory, but I slightly recall aiming at using those 12-bytes of
padding for new feature extensions, in which case a version field would have helped.
But it appears we will very soon run out of space there and need to extend the
structure size anyway, so trying to re-purpose those 12 bytes might not be worth
the complexity.

Considering the userspace ABI exposed by glibc 2.35 (__rseq_offset, __rseq_size,
__rseq_flags), the "size" of the rseq structure becomes a really good fit for
available feature description across the entire ecosystem consisting of the kernel,
libc, and user applications. If we add a "version" field in there, then applications
would have to check yet one more thing in addition to the __rseq_size, which I
don't think is worthwhile.

> 
>> +
>> +       /*
>> +        * This is the end of the original rseq ABI.
>> +        * This is a valid end of rseq ABI for the purpose of rseq registration
>> +        * rseq_len.
>> +        * The original rseq ABI use "sizeof(struct rseq)" on registration,
>> +        * thus requiring the padding above.
>> +        */
>> +
>> +       /*
>> +        * Restartable sequences node_id field. Updated by the kernel. Read by
>> +        * user-space with single-copy atomicity semantics. This field should
>> +        * only be read by the thread which registered this data structure.
>> +        * Aligned on 32-bit. Contains the current NUMA node ID.
>> +        */
>> +       __u32 node_id;
>> +
>> +       /*
>> +        * This is a valid end of rseq ABI for the purpose of rseq registration
>> +        * rseq_len. Use the offset immediately after the node_id field as
>> +        * rseq_len.
>> +        */
>>  } __attribute__((aligned(4 * sizeof(__u64))));

Thanks!

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com