On Mon, May 29 2023 at 15:14, Mathieu Desnoyers wrote:
> +/*
> + * rseq_sched_state should be aligned on the cache line size.
> + */
> +struct rseq_sched_state {
> + /*
> + * Version of this structure. Populated by the kernel, read by
> + * user-space.
> + */
> + __u32 version;
> + /*
> + * The state is updated by the kernel. Read by user-space with
> + * single-copy atomicity semantics. This field can be read by any
> + * userspace thread. Aligned on 32-bit. Contains a bitmask of enum
> + * rseq_sched_state_flags. This field is provided as a hint by the
> + * scheduler, and requires that the page holding this state is
> + * faulted-in for the state update to be performed by the scheduler.
> + */
> + __u32 state;
> + /*
> + * Thread ID associated with the thread registering this structure.
> + * Initialized by user-space before registration.
> + */
> + __u32 tid;
> +};
> +
> /*
> * struct rseq is aligned on 4 * 8 bytes to ensure it is always
> * contained within a single cache-line.
> @@ -148,6 +180,15 @@ struct rseq {
> */
> __u32 mm_cid;
>
> + __u32 padding1;
> +
> + /*
> + * Restartable sequences sched_state_ptr field. Initialized by
> + * userspace to the address at which the struct rseq_sched_state is
> + * located. Read by the kernel on rseq registration.
> + */
> + __u64 sched_state_ptr;
> +
Why is this a separate entity instead of being simply embedded into
struct rseq?
Neither the code comment nor the changelog tells anything about that.
If your intention was to provide a solution for process shared futexes
then you completely failed to understand how process shared futexes
work. If not, then please explain why you need a pointer and the
associated hackery to deal with it.
Thanks,
tglx
