linux-toradex.git/include/uapi/linux/rseq.h, branch v7.0-rc6

rseq: slice ext: Ensure rseq feature size differs from original rseq size

2026-02-23T10:19:19+00:00

Before rseq became extensible, its original size was 32 bytes even
though the active rseq area was only 20 bytes. This had the following
impact in terms of userspace ecosystem evolution:

* The GNU libc between 2.35 and 2.39 expose a __rseq_size symbol set
  to 32, even though the size of the active rseq area is really 20.
* The GNU libc 2.40 changes this __rseq_size to 20, thus making it
  express the active rseq area.
* Starting from glibc 2.41, __rseq_size corresponds to the
  AT_RSEQ_FEATURE_SIZE from getauxval(3).

This means that users of __rseq_size can always expect it to
correspond to the active rseq area, except for the value 32, for
which the active rseq area is 20 bytes.

Exposing a 32 bytes feature size would make life needlessly painful
for userspace. Therefore, add a reserved field at the end of the
rseq area to bump the feature size to 33 bytes. This reserved field
is expected to be replaced with whatever field will come next,
expecting that this field will be larger than 1 byte.

The effect of this change is to increase the size from 32 to 64 bytes
before we actually have fields using that memory.

Clarify the allocation size and alignment requirements in the struct
rseq uapi comment.

Change the value returned by getauxval(AT_RSEQ_ALIGN) to return the
value of the active rseq area size rounded up to next power of 2, which
guarantees that the rseq structure will always be aligned on the nearest
power of two large enough to contain it, even as it grows. Change the
alignment check in the rseq registration accordingly.

This will minimize the amount of ABI corner-cases we need to document
and require userspace to play games with. The rule stays simple when
__rseq_size != 32:

  #define rseq_field_available(field)	(__rseq_size >= offsetofend(struct rseq_abi, field))

Signed-off-by: Mathieu Desnoyers 
Signed-off-by: Peter Zijlstra (Intel) 
Link: https://patch.msgid.link/20260220200642.1317826-3-mathieu.desnoyers@efficios.com

rseq: Allow registering RSEQ with slice extension

2026-01-22T10:11:19+00:00

Since glibc cares about the number of syscalls required to initialize a new
thread, allow initializing rseq with slice extension on. This avoids having to
do another prctl().

Requested-by: Mathieu Desnoyers 
Signed-off-by: Peter Zijlstra (Intel) 
Link: https://patch.msgid.link/20260121143207.814193010@infradead.org

rseq: Add fields and constants for time slice extension

2026-01-22T10:11:16+00:00

Aside of a Kconfig knob add the following items:

   - Two flag bits for the rseq user space ABI, which allow user space to
     query the availability and enablement without a syscall.

   - A new member to the user space ABI struct rseq, which is going to be
     used to communicate request and grant between kernel and user space.

   - A rseq state struct to hold the kernel state of this

   - Documentation of the new mechanism

Signed-off-by: Thomas Gleixner 
Signed-off-by: Peter Zijlstra (Intel) 
Link: https://patch.msgid.link/20251215155708.669472597@linutronix.de

rseq: Simplify the event notification

2025-11-04T07:30:09+00:00

Since commit 0190e4198e47 ("rseq: Deprecate RSEQ_CS_FLAG_NO_RESTART_ON_*
flags") the bits in task::rseq_event_mask are meaningless and just extra
work in terms of setting them individually.

Aside of that the only relevant point where an event has to be raised is
context switch. Neither the CPU nor MM CID can change without going through
a context switch.

Collapse them all into a single boolean which simplifies the code a lot and
remove the pointless invocations which have been sprinkled all over the
place for no value.

Signed-off-by: Thomas Gleixner 
Signed-off-by: Peter Zijlstra (Intel) 
Signed-off-by: Ingo Molnar 
Reviewed-by: Mathieu Desnoyers 
Link: https://patch.msgid.link/20251027084306.336978188@linutronix.de

rseq: Extend struct rseq with per-memory-map concurrency ID

2022-12-27T11:52:12+00:00

If a memory map has fewer threads than there are cores on the system, or
is limited to run on few cores concurrently through sched affinity or
cgroup cpusets, the concurrency IDs will be values close to 0, thus
allowing efficient use of user-space memory for per-cpu data structures.

Signed-off-by: Mathieu Desnoyers 
Signed-off-by: Peter Zijlstra (Intel) 
Link: https://lore.kernel.org/r/20221122203932.231377-9-mathieu.desnoyers@efficios.com

rseq: Extend struct rseq with numa node id

2022-12-27T11:52:10+00:00

Adding the NUMA node id to struct rseq is a straightforward thing to do,
and a good way to figure out if anything in the user-space ecosystem
prevents extending struct rseq.

This NUMA node id field allows memory allocators such as tcmalloc to
take advantage of fast access to the current NUMA node id to perform
NUMA-aware memory allocation.

It can also be useful for implementing fast-paths for NUMA-aware
user-space mutexes.

It also allows implementing getcpu(2) purely in user-space.

Signed-off-by: Mathieu Desnoyers 
Signed-off-by: Peter Zijlstra (Intel) 
Link: https://lore.kernel.org/r/20221122203932.231377-5-mathieu.desnoyers@efficios.com

rseq: Introduce feature size and alignment ELF auxiliary vector entries

2022-12-27T11:52:10+00:00

Export the rseq feature size supported by the kernel as well as the
required allocation alignment for the rseq per-thread area to user-space
through ELF auxiliary vector entries.

This is part of the extensible rseq ABI.

Signed-off-by: Mathieu Desnoyers 
Signed-off-by: Peter Zijlstra (Intel) 
Link: https://lore.kernel.org/r/20221122203932.231377-3-mathieu.desnoyers@efficios.com

rseq: Remove broken uapi field layout on 32-bit little endian

2022-02-02T12:11:34+00:00

The rseq rseq_cs.ptr.{ptr32,padding} uapi endianness handling is
entirely wrong on 32-bit little endian: a preprocessor logic mistake
wrongly uses the big endian field layout on 32-bit little endian
architectures.

Fortunately, those ptr32 accessors were never used within the kernel,
and only meant as a convenience for user-space.

Remove those and replace the whole rseq_cs union by a __u64 type, as
this is the only thing really needed to express the ABI. Document how
32-bit architectures are meant to interact with this field.

Fixes: ec9c82e03a74 ("rseq: uapi: Declare rseq_cs field as union, update includes")
Signed-off-by: Mathieu Desnoyers 
Signed-off-by: Peter Zijlstra (Intel) 
Link: https://lkml.kernel.org/r/20220127152720.25898-1-mathieu.desnoyers@efficios.com

rseq: uapi: Declare rseq_cs field as union, update includes

2018-07-10T20:18:52+00:00

Declaring the rseq_cs field as a union between __u64 and two __u32
allows both 32-bit and 64-bit kernels to read the full __u64, and
therefore validate that a 32-bit user-space cleared the upper 32
bits, thus ensuring a consistent behavior between native 32-bit
kernels and 32-bit compat tasks on 64-bit kernels.

Check that the rseq_cs value read is < TASK_SIZE.

The asm/byteorder.h header needs to be included by rseq.h, now
that it is not using linux/types_32_64.h anymore.

Considering that only __32 and __u64 types are declared in linux/rseq.h,
the linux/types.h header should always be included for both kernel and
user-space code: including stdint.h is just for u64 and u32, which are
not used in this header at all.

Use copy_from_user()/clear_user() to interact with a 64-bit field,
because arm32 does not implement 64-bit __get_user, and ppc32 does not
64-bit get_user. Considering that the rseq_cs pointer does not need to
be loaded/stored with single-copy atomicity from the kernel anymore, we
can simply use copy_from_user()/clear_user().

Signed-off-by: Mathieu Desnoyers 
Signed-off-by: Thomas Gleixner 
Cc: linux-api@vger.kernel.org
Cc: Peter Zijlstra 
Cc: "Paul E . McKenney" 
Cc: Boqun Feng 
Cc: Andy Lutomirski 
Cc: Dave Watson 
Cc: Paul Turner 
Cc: Andrew Morton 
Cc: Russell King 
Cc: "H . Peter Anvin" 
Cc: Andi Kleen 
Cc: Chris Lameter 
Cc: Ben Maurer 
Cc: Steven Rostedt 
Cc: Josh Triplett 
Cc: Linus Torvalds 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Michael Kerrisk 
Cc: Joel Fernandes 
Cc: "Paul E. McKenney" 
Cc: "H. Peter Anvin" 
Link: https://lkml.kernel.org/r/20180709195155.7654-5-mathieu.desnoyers@efficios.com

rseq: uapi: Update uapi comments

2018-07-10T20:18:52+00:00

Update rseq uapi header comments to reflect that user-space need to do
thread-local loads/stores from/to the struct rseq fields.

As a consequence of this added requirement, the kernel does not need
to perform loads/stores with single-copy atomicity.

Update the comment associated to the "flags" fields to describe
more accurately that it's only useful to facilitate single-stepping
through rseq critical sections with debuggers.

Signed-off-by: Mathieu Desnoyers 
Signed-off-by: Thomas Gleixner 
Cc: linux-api@vger.kernel.org
Cc: Peter Zijlstra 
Cc: "Paul E . McKenney" 
Cc: Boqun Feng 
Cc: Andy Lutomirski 
Cc: Dave Watson 
Cc: Paul Turner 
Cc: Andrew Morton 
Cc: Russell King 
Cc: "H . Peter Anvin" 
Cc: Andi Kleen 
Cc: Chris Lameter 
Cc: Ben Maurer 
Cc: Steven Rostedt 
Cc: Josh Triplett 
Cc: Linus Torvalds 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Michael Kerrisk 
Cc: Joel Fernandes 
Cc: "Paul E. McKenney" 
Cc: "H. Peter Anvin" 
Link: https://lkml.kernel.org/r/20180709195155.7654-4-mathieu.desnoyers@efficios.com