<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/tools/testing/selftests/rseq/rseq.c, branch v6.1.168</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1.168</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1.168'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2025-10-19T14:23:16+00:00</updated>
<entry>
<title>rseq/selftests: Use weak symbol reference, not definition, to link with glibc</title>
<updated>2025-10-19T14:23:16+00:00</updated>
<author>
<name>Sean Christopherson</name>
<email>seanjc@google.com</email>
</author>
<published>2025-08-19T22:29:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fcd4c9075eca28d00808d580912bbe64c8b33010'/>
<id>urn:sha1:fcd4c9075eca28d00808d580912bbe64c8b33010</id>
<content type='text'>
commit a001cd248ab244633c5fabe4f7c707e13fc1d1cc upstream.

Add "extern" to the glibc-defined weak rseq symbols to convert the rseq
selftest's usage from weak symbol definitions to weak symbol _references_.
Effectively re-defining the glibc symbols wreaks havoc when building with
-fno-common, e.g. generates segfaults when running multi-threaded programs,
as dynamically linked applications end up with multiple versions of the
symbols.

Building with -fcommon, which until recently has the been the default for
GCC and clang, papers over the bug by allowing the linker to resolve the
weak/tentative definition to glibc's "real" definition.

Note, the symbol itself (or rather its address), not the value of the
symbol, is set to 0/NULL for unresolved weak symbol references, as the
symbol doesn't exist and thus can't have a value.  Check for a NULL rseq
size pointer to handle the scenario where the test is statically linked
against a libc that doesn't support rseq in any capacity.

Fixes: 3bcbc20942db ("selftests/rseq: Play nice with binaries statically linked against glibc 2.35+")
Reported-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Suggested-by: Florian Weimer &lt;fweimer@redhat.com&gt;
Signed-off-by: Sean Christopherson &lt;seanjc@google.com&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Reviewed-by: Mathieu Desnoyers &lt;mathieu.desnoyers@efficios.com&gt;
Cc: stable@vger.kernel.org
Closes: https://lore.kernel.org/all/87frdoybk4.ffs@tglx
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>selftests/rseq: Fix build with undefined __weak</title>
<updated>2023-08-16T16:27:25+00:00</updated>
<author>
<name>Mark Brown</name>
<email>broonie@kernel.org</email>
</author>
<published>2023-08-04T19:22:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e146162dcf2e4d486df8d76f6587b8819cf538bc'/>
<id>urn:sha1:e146162dcf2e4d486df8d76f6587b8819cf538bc</id>
<content type='text'>
commit d5ad9aae13dcced333c1a7816ff0a4fbbb052466 upstream.

Commit 3bcbc20942db ("selftests/rseq: Play nice with binaries statically
linked against glibc 2.35+") which is now in Linus' tree introduced uses
of __weak but did nothing to ensure that a definition is provided for it
resulting in build failures for the rseq tests:

rseq.c:41:1: error: unknown type name '__weak'
__weak ptrdiff_t __rseq_offset;
^
rseq.c:41:17: error: expected ';' after top level declarator
__weak ptrdiff_t __rseq_offset;
                ^
                ;
rseq.c:42:1: error: unknown type name '__weak'
__weak unsigned int __rseq_size;
^
rseq.c:43:1: error: unknown type name '__weak'
__weak unsigned int __rseq_flags;

Fix this by using the definition from tools/include compiler.h.

Fixes: 3bcbc20942db ("selftests/rseq: Play nice with binaries statically linked against glibc 2.35+")
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Message-Id: &lt;20230804-kselftest-rseq-build-v1-1-015830b66aa9@kernel.org&gt;
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>selftests/rseq: Play nice with binaries statically linked against glibc 2.35+</title>
<updated>2023-08-11T10:08:26+00:00</updated>
<author>
<name>Sean Christopherson</name>
<email>seanjc@google.com</email>
</author>
<published>2023-07-21T22:33:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e355972affb67aa2e9b6daa6d77008a6b88abcdf'/>
<id>urn:sha1:e355972affb67aa2e9b6daa6d77008a6b88abcdf</id>
<content type='text'>
[ Upstream commit 3bcbc20942db5d738221cca31a928efc09827069 ]

To allow running rseq and KVM's rseq selftests as statically linked
binaries, initialize the various "trampoline" pointers to point directly
at the expect glibc symbols, and skip the dlysm() lookups if the rseq
size is non-zero, i.e. the binary is statically linked *and* the libc
registered its own rseq.

Define weak versions of the symbols so as not to break linking against
libc versions that don't support rseq in any capacity.

The KVM selftests in particular are often statically linked so that they
can be run on targets with very limited runtime environments, i.e. test
machines.

Fixes: 233e667e1ae3 ("selftests/rseq: Uplift rseq selftests for compatibility with glibc-2.35")
Cc: Aaron Lewis &lt;aaronlewis@google.com&gt;
Cc: kvm@vger.kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: Sean Christopherson &lt;seanjc@google.com&gt;
Message-Id: &lt;20230721223352.2333911-1-seanjc@google.com&gt;
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>selftests/rseq: check if libc rseq support is registered</title>
<updated>2022-06-28T07:08:28+00:00</updated>
<author>
<name>Michael Jeanson</name>
<email>mjeanson@efficios.com</email>
</author>
<published>2022-06-14T15:48:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d1a997ba4c1bf65497d956aea90de42a6398f73a'/>
<id>urn:sha1:d1a997ba4c1bf65497d956aea90de42a6398f73a</id>
<content type='text'>
When checking for libc rseq support in the library constructor, don't
only depend on the symbols presence, check that the registration was
completed.

This targets a scenario where the libc has rseq support but it is not
wired for the current architecture in 'bits/rseq.h', we want to fallback
to our internal registration mechanism.

Signed-off-by: Michael Jeanson &lt;mjeanson@efficios.com&gt;
Signed-off-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Reviewed-by: Mathieu Desnoyers &lt;mathieu.desnoyers@efficios.com&gt;
Link: https://lore.kernel.org/r/20220614154830.1367382-4-mjeanson@efficios.com
</content>
</entry>
<entry>
<title>selftests/rseq: Change type of rseq_offset to ptrdiff_t</title>
<updated>2022-02-11T22:30:08+00:00</updated>
<author>
<name>Mathieu Desnoyers</name>
<email>mathieu.desnoyers@efficios.com</email>
</author>
<published>2022-02-03T15:05:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=889c5d60fbcf332c8b6ab7054d45f2768914a375'/>
<id>urn:sha1:889c5d60fbcf332c8b6ab7054d45f2768914a375</id>
<content type='text'>
Just before the 2.35 release of glibc, the __rseq_offset userspace ABI
was changed from int to ptrdiff_t.

Adapt to this change in the kernel selftests.

Signed-off-by: Mathieu Desnoyers &lt;mathieu.desnoyers@efficios.com&gt;
Signed-off-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Link: https://sourceware.org/pipermail/libc-alpha/2022-February/136024.html
</content>
</entry>
<entry>
<title>selftests/rseq: Uplift rseq selftests for compatibility with glibc-2.35</title>
<updated>2022-02-02T12:11:35+00:00</updated>
<author>
<name>Mathieu Desnoyers</name>
<email>mathieu.desnoyers@efficios.com</email>
</author>
<published>2022-01-24T17:12:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=233e667e1ae3e348686bd9dd0172e62a09d852e1'/>
<id>urn:sha1:233e667e1ae3e348686bd9dd0172e62a09d852e1</id>
<content type='text'>
glibc-2.35 (upcoming release date 2022-02-01) exposes the rseq per-thread
data in the TCB, accessible at an offset from the thread pointer, rather
than through an actual Thread-Local Storage (TLS) variable, as the
Linux kernel selftests initially expected.

The __rseq_abi TLS and glibc-2.35's ABI for per-thread data cannot
actively coexist in a process, because the kernel supports only a single
rseq registration per thread.

Here is the scheme introduced to ensure selftests can work both with an
older glibc and with glibc-2.35+:

- librseq exposes its own "rseq_offset, rseq_size, rseq_flags" ABI.

- librseq queries for glibc rseq ABI (__rseq_offset, __rseq_size,
  __rseq_flags) using dlsym() in a librseq library constructor. If those
  are found, copy their values into rseq_offset, rseq_size, and
  rseq_flags.

- Else, if those glibc symbols are not found, handle rseq registration
  from librseq and use its own IE-model TLS to implement the rseq ABI
  per-thread storage.

Signed-off-by: Mathieu Desnoyers &lt;mathieu.desnoyers@efficios.com&gt;
Signed-off-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Link: https://lkml.kernel.org/r/20220124171253.22072-8-mathieu.desnoyers@efficios.com
</content>
</entry>
<entry>
<title>selftests/rseq: Remove volatile from __rseq_abi</title>
<updated>2022-02-02T12:11:34+00:00</updated>
<author>
<name>Mathieu Desnoyers</name>
<email>mathieu.desnoyers@efficios.com</email>
</author>
<published>2022-01-24T17:12:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=94b80a19ebfe347a01301d750040a61c38200e2b'/>
<id>urn:sha1:94b80a19ebfe347a01301d750040a61c38200e2b</id>
<content type='text'>
This is done in preparation for the selftest uplift to become compatible
with glibc-2.35.

All accesses to the __rseq_abi fields are volatile, but remove the
volatile from the TLS variable declaration, otherwise we are stuck with
volatile for the upcoming rseq_get_abi() helper.

Signed-off-by: Mathieu Desnoyers &lt;mathieu.desnoyers@efficios.com&gt;
Signed-off-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Link: https://lkml.kernel.org/r/20220124171253.22072-5-mathieu.desnoyers@efficios.com
</content>
</entry>
<entry>
<title>selftests/rseq: introduce own copy of rseq uapi header</title>
<updated>2022-02-02T12:11:33+00:00</updated>
<author>
<name>Mathieu Desnoyers</name>
<email>mathieu.desnoyers@efficios.com</email>
</author>
<published>2022-01-24T17:12:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5c105d55a9dc9e01535116ccfc26e703168a574f'/>
<id>urn:sha1:5c105d55a9dc9e01535116ccfc26e703168a574f</id>
<content type='text'>
The Linux kernel rseq uapi header has a broken layout for the
rseq_cs.ptr field on 32-bit little endian architectures. The entire
rseq_cs.ptr field is planned for removal, leaving only the 64-bit
rseq_cs.ptr64 field available.

Both glibc and librseq use their own copy of the Linux kernel uapi
header, where they introduce proper union fields to access to the 32-bit
low order bits of the rseq_cs pointer on 32-bit architectures.

Introduce a copy of the Linux kernel uapi headers in the Linux kernel
selftests.

Signed-off-by: Mathieu Desnoyers &lt;mathieu.desnoyers@efficios.com&gt;
Signed-off-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Link: https://lkml.kernel.org/r/20220124171253.22072-2-mathieu.desnoyers@efficios.com
</content>
</entry>
<entry>
<title>selftests/rseq: remove ARRAY_SIZE define from individual tests</title>
<updated>2021-12-11T00:51:03+00:00</updated>
<author>
<name>Shuah Khan</name>
<email>skhan@linuxfoundation.org</email>
</author>
<published>2021-12-09T23:19:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=07ad4f7629d4802ff0d962b0ac23ea6445964e2a'/>
<id>urn:sha1:07ad4f7629d4802ff0d962b0ac23ea6445964e2a</id>
<content type='text'>
ARRAY_SIZE is defined in several selftests. Remove definitions from
individual test files and include header file for the define instead.
ARRAY_SIZE define is added in a separate patch to prepare for this
change.

Remove ARRAY_SIZE from rseq tests and pickup the one defined in
kselftest.h.

Signed-off-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>rseq/selftests: Use __rseq_handled symbol to coexist with glibc</title>
<updated>2019-05-07T21:31:46+00:00</updated>
<author>
<name>Mathieu Desnoyers</name>
<email>mathieu.desnoyers@efficios.com</email>
</author>
<published>2019-04-29T15:27:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5b0c308a0565a94d2e1070cbf287197b676faaaf'/>
<id>urn:sha1:5b0c308a0565a94d2e1070cbf287197b676faaaf</id>
<content type='text'>
In order to integrate rseq into user-space applications, expose a
__rseq_handled symbol so many rseq users can be linked into the same
application (e.g. librseq and glibc).

The __rseq_refcount TLS variable is static to the librseq library. It
ensures that rseq syscall registration/unregistration happens only for
the most early/late caller to rseq_{,un}register_current_thread for each
thread, thus ensuring that rseq is registered across the lifetime of all
rseq users for a given thread.

Signed-off-by: Mathieu Desnoyers &lt;mathieu.desnoyers@efficios.com&gt;
CC: Shuah Khan &lt;shuah@kernel.org&gt;
CC: Carlos O'Donell &lt;carlos@redhat.com&gt;
CC: Florian Weimer &lt;fweimer@redhat.com&gt;
CC: Joseph Myers &lt;joseph@codesourcery.com&gt;
CC: Szabolcs Nagy &lt;szabolcs.nagy@arm.com&gt;
CC: Thomas Gleixner &lt;tglx@linutronix.de&gt;
CC: Ben Maurer &lt;bmaurer@fb.com&gt;
CC: Peter Zijlstra &lt;peterz@infradead.org&gt;
CC: "Paul E. McKenney" &lt;paulmck@linux.vnet.ibm.com&gt;
CC: Boqun Feng &lt;boqun.feng@gmail.com&gt;
CC: Will Deacon &lt;will.deacon@arm.com&gt;
CC: Dave Watson &lt;davejwatson@fb.com&gt;
CC: Paul Turner &lt;pjt@google.com&gt;
CC: linux-api@vger.kernel.org
Signed-off-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
</content>
</entry>
</feed>
