Re: [patch 02/12] rseq: Add fields and constants for time slice extension

Prakash Sangappa
2025-09-22T05:29:41Z

> On Sep 8, 2025, at 3:59 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
>
..
> +enum rseq_slice_masks {
> + RSEQ_SLICE_EXT_REQUEST = (1U << RSEQ_SLICE_EXT_REQUEST_BIT),
> + RSEQ_SLICE_EXT_GRANTED = (1U << RSEQ_SLICE_EXT_GRANTED_BIT),
> };
>
> /*
> @@ -142,6 +164,12 @@ struct rseq {
> __u32 mm_cid;
>
> /*
> + * Time slice extension control word. CPU local atomic updates from
> + * kernel and user space.
> + */
> + __u32 slice_ctrl;

We intend to backport the slice extension feature to older kernel versions.

With use of a new structure member for slice control, could there be discrepancy
with rseq structure size(older version) registered by libc? In that case the application
may not be able to use slice extension feature unless Libc’s use of rseq is disabled.

Application would have to verify structure size, so should it be mentioned in the
documentation. Also, perhaps make the prctl() enable call return error, if structure size
does not match?

With regards to application determining the address and size of rseq structure
registered by libc, what are you thoughts on getting that thru the rseq(2)
system call or a prctl() call instead of dealing with the __week symbols as was discussed here.

https://lore.kernel.org/all/F9DBABAD-ABF0-49AA-9A38-BD4D2BE78B94@oracle.com/

Thanks,
-Prakash

> +
> + /*
> * Flexible array member at end of structure, after last feature field.
> */
> char end[];