mirror of
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
synced 2025-08-05 16:54:27 +00:00
6eda706a53
vdso_test_correctness test fails on powerpc: ~ # ./vdso_test_correctness ... [RUN] Testing clock_gettime for clock CLOCK_REALTIME_ALARM (8)... [FAIL] No such clock, but __vdso_clock_gettime returned 22 [RUN] Testing clock_gettime for clock CLOCK_BOOTTIME_ALARM (9)... [FAIL] No such clock, but __vdso_clock_gettime returned 22 [RUN] Testing clock_gettime for clock CLOCK_SGI_CYCLE (10)... [FAIL] No such clock, but __vdso_clock_gettime returned 22 ... [RUN] Testing clock_gettime for clock invalid (-1)... [FAIL] No such clock, but __vdso_clock_gettime returned 22 [RUN] Testing clock_gettime for clock invalid (-2147483648)... [FAIL] No such clock, but __vdso_clock_gettime returned 22 [RUN] Testing clock_gettime for clock invalid (2147483647)... [FAIL] No such clock, but __vdso_clock_gettime returned 22 On powerpc, a call to a VDSO function is not an ordinary C function call. Unlike several architectures which returns a negative error code in case of an error, powerpc sets CR[SO] and returns the error code as a positive value. Define and use a macro called VDSO_CALL() which takes a pointer to the function to call, the number of arguments and the arguments. Also update ABI vdso documentation to reflect this subtlety. Provide a specific version of VDSO_CALL() for powerpc that negates the error code on return when CR[SO] is set. Fixes:c7e5789b24("kselftest: Move test_vdso to the vDSO test suite") Fixes:2e9a972566("selftests: vdso: Add a selftest for vDSO getcpu()") Fixes:693f5ca08c("kselftest: Extend vDSO selftest") Fixes:b2f1c3db28("kselftest: Extend vdso correctness test to clock_gettime64") Fixes:4920a2590e("selftests/vDSO: add tests for vgetrandom") Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Acked-by: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
37 lines
1.6 KiB
Text
37 lines
1.6 KiB
Text
What: vDSO
|
|
Date: July 2011
|
|
KernelVersion: 3.0
|
|
Contact: Andy Lutomirski <luto@kernel.org>
|
|
Description:
|
|
|
|
On some architectures, when the kernel loads any userspace program it
|
|
maps an ELF DSO into that program's address space. This DSO is called
|
|
the vDSO and it often contains useful and highly-optimized alternatives
|
|
to real syscalls.
|
|
|
|
These functions are called according to your platform's ABI. On many
|
|
platforms they are called just like ordinary C function. On other platforms
|
|
(ex: powerpc) they are called with the same convention as system calls which
|
|
is different from ordinary C functions. Call them from a sensible context.
|
|
(For example, if you set CS on x86 to something strange, the vDSO functions are
|
|
within their rights to crash.) In addition, if you pass a bad
|
|
pointer to a vDSO function, you might get SIGSEGV instead of -EFAULT.
|
|
|
|
To find the DSO, parse the auxiliary vector passed to the program's
|
|
entry point. The AT_SYSINFO_EHDR entry will point to the vDSO.
|
|
|
|
The vDSO uses symbol versioning; whenever you request a symbol from the
|
|
vDSO, specify the version you are expecting.
|
|
|
|
Programs that dynamically link to glibc will use the vDSO automatically.
|
|
Otherwise, you can use the reference parser in
|
|
tools/testing/selftests/vDSO/parse_vdso.c.
|
|
|
|
Unless otherwise noted, the set of symbols with any given version and the
|
|
ABI of those symbols is considered stable. It may vary across architectures,
|
|
though.
|
|
|
|
Note:
|
|
As of this writing, this ABI documentation as been confirmed for x86_64.
|
|
The maintainers of the other vDSO-using architectures should confirm
|
|
that it is correct for their architecture.
|