- 13 Sep, 2024 30 commits
-
-
Heiko Carstens authored
The vdso.h header file, which is included at many places, includes generated header files. This can easily lead to recursive header file inclusions if the vdso code is changed. Therefore move the vdso symbol code, which requires the generated header files, to a separate header file, and include it at the two locations which require it. Signed-off-by:
Heiko Carstens <hca@linux.ibm.com> Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com>
-
Heiko Carstens authored
Implement the infrastructure required to allow alternatives in vdso code. Signed-off-by:
-
Heiko Carstens authored
Provide find_section() helper function which can be used to find a section by name, similar to other architectures. Signed-off-by:
-
Heiko Carstens authored
Let test_facility() generate a branch instruction if the tested facility is a constant, and where the result cannot be evaluated during compile time. The branch instruction defaults to "false" and is patched to nop (branch not taken) if the tested facility is available. This avoids runtime checks and is similar to x86's static_cpu_has() and arm64's alternative_has_cap_likely(). Signed-off-by:
-
Heiko Carstens authored
Patch all alternatives which depend on facilities from the decompressor. There is no technical reason which enforces to split patching of such alternatives to the decompressor and the kernel. This simplifies alternative handling a bit, since one alternative type is removed. Signed-off-by:
-
Heiko Carstens authored
Disable compile time optimizations of test_facility() for the decompressor. The decompressor should not contain any optimized code depending on the architecture level set the kernel image is compiled for to avoid unexpected operation exceptions. Add a __DECOMPRESSOR check to test_facility() to enforce that facilities are always checked during runtime for the decompressor. Reviewed-by:
Sven Schnelle <svens@linux.ibm.com> Signed-off-by:
-
Heiko Carstens authored
Running vdso_test_correctness on s390x (aka s390 64 bit) emits a warning: Warning: failed to find clock_gettime64 in vDSO This is caused by the "#elif defined (__s390__)" check in vdso_config.h which the defines VDSO_32BIT. If __s390x__ is defined also __s390__ is defined. Therefore the correct check must make sure that only __s390__ is defined. Therefore add the missing !defined(__s390x__). Also use common __s390x__ define instead of __s390X__. Signed-off-by:
-
Jens Remus authored
The vDSO self tests fail on s390x for a vDSO linked with the GNU linker ld as follows: # ./vdso_test_gettimeofday Floating point exception (core dumped) On s390x the ELF hash table entries are 64 bits instead of 32 bits in size (see Glibc sysdeps/unix/sysv/linux/s390/bits/elfclass.h). Fixes: 40723419 ("kselftest: Enable vDSO test on non x86 platforms") Reported-by:
Jens Remus <jremus@linux.ibm.com> Signed-off-by:
-
Christophe Leroy authored
Extend getrandom() vDSO implementation to VDSO64. Tested on QEMU on both ppc64_defconfig and ppc64le_defconfig. Results from a Power9 (PowerNV): ~ # ./vdso_test_getrandom bench-single vdso: 25000000 times in 0.787943615 seconds libc: 25000000 times in 14.101887252 seconds syscall: 25000000 times in 14.047475082 seconds Signed-off-by:
Christophe Leroy <christophe.leroy@csgroup.eu> Tested-by:
Madhavan Srinivasan <maddy@linux.ibm.com> Acked-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Christophe Leroy authored
To be consistent with other VDSO functions, the function is called __kernel_getrandom() __arch_chacha20_blocks_nostack() fonction is implemented basically with 32 bits operations. It performs 4 QUARTERROUND operations in parallele. There are enough registers to avoid using the stack: On input: r3: output bytes r4: 32-byte key input r5: 8-byte counter input/output r6: number of 64-byte blocks to write to output During operation: stack: pointer to counter (r5) and non-volatile registers (r14-131) r0: counter of blocks (initialised with r6) r4: Value '4' after key has been read, used for indexing r5-r12: key r14-r15: block counter r16-r31: chacha state At the end: r0, r6-r12: Zeroised r5, r14-r31: Restored Performance on powerpc 885 (using kernel selftest): ~# ./vdso_test_getrandom bench-single vdso: 25000000 times in 62.938002291 seconds libc: 25000000 times in 535.581916866 seconds syscall: 25000000 times in 531.525042806 seconds Performance on powerpc 8321 (using kernel selftest): ~# ./vdso_test_getrandom bench-single vdso: 25000000 times in 16.899318858 seconds libc: 25000000 times in 131.050596522 seconds syscall: 25000000 times in 129.794790389 seconds This first patch adds support for VDSO32. As selftests cannot easily be generated only for VDSO32, and because the following patch brings support for VDSO64 anyway, this patch opts out all code in __arch_chacha20_blocks_nostack() so that vdso_test_chacha will not fail to compile and will not crash on PPC64/PPC64LE, allthough the selftest itself will fail. Signed-off-by:
-
Christophe Leroy authored
In order to avoid two much duplication when we add new VDSO functionnalities in C like getrandom, refactor common CFLAGS. Signed-off-by:
-
Christophe Leroy authored
Commit 08c18b63 ("powerpc/vdso32: Add missing _restgpr_31_x to fix build failure") added _restgpr_31_x to the vdso for gettimeofday, but the work on getrandom shows that we will need more of those functions. Remove _restgpr_31_x and link in crtsavres.o so that we get all save/restore functions when optimising the kernel for size. Signed-off-by:
Ard Biesheuvel <ardb@kernel.org> Acked-by:
-
Christophe Leroy authored
Commit 9651fced ("mm: add MAP_DROPPABLE for designating always lazily freeable mappings") only adds VM_DROPPABLE for 64 bits architectures. In order to also use the getrandom vDSO implementation on powerpc/32, use VM_ARCH_1 for VM_DROPPABLE on powerpc/32. This is possible because VM_ARCH_1 is used for VM_SAO on powerpc and VM_SAO is only for powerpc/64. It is used in combination with PROT_SAO in some parts of code that are restricted to CONFIG_PPC64 through #ifdefs, it is therefore possible to define VM_SAO for CONFIG_PPC64 only. Signed-off-by:
-
Christophe Leroy authored
When running in a non-root time namespace, the global VDSO data page is replaced by a dedicated namespace data page and the global data page is mapped next to it. Detailed explanations can be found at commit 660fd04f ("lib/vdso: Prepare for time namespace support"). When it happens, __kernel_get_syscall_map and __kernel_get_tbfreq and __kernel_sync_dicache don't work anymore because they read 0 instead of the data they need. To address that, clock_mode has to be read. When it is set to VDSO_CLOCKMODE_TIMENS, it means it is a dedicated namespace data page and the global data is located on the following page. Add a macro called get_realdatapage which reads clock_mode and add PAGE_SIZE to the pointer provided by get_datapage macro when clock_mode is equal to VDSO_CLOCKMODE_TIMENS. Use this new macro instead of get_datapage macro except for time functions as they handle it internally. Fixes: 74205b3f ("powerpc/vdso: Add support for time namespaces") Reported-by:
-
Jason A. Donenfeld authored
It's not correct to use $(top_srcdir) for generated header files, for builds that are done out of tree via O=, and $(objtree) isn't valid in the selftests context. Instead, just obviate the need for these generated header files by defining empty stubs in tools/include, which is the same thing that's done for rwlock.h. Reviewed-by:
Adhemerval Zanella <adhemerval.zanella@linaro.org> Signed-off-by:
-
Adhemerval Zanella authored
Hook up the generic vDSO implementation to the aarch64 vDSO data page. The _vdso_rng_data required data is placed within the _vdso_data vvar page, by using a offset larger than the vdso_data. The vDSO function requires a ChaCha20 implementation that does not write to the stack, and that can do an entire ChaCha20 permutation. The one provided uses NEON on the permute operation, with a fallback to the syscall for chips that do not support AdvSIMD. This also passes the vdso_test_chacha test along with vdso_test_getrandom. The vdso_test_getrandom bench-single result on Neoverse-N1 shows: vdso: 25000000 times in 0.783884250 seconds libc: 25000000 times in 8.780275399 seconds syscall: 25000000 times in 8.786581518 seconds A small fixup to arch/arm64/include/asm/mman.h was required to avoid pulling kernel code into the vDSO, similar to what's already done in arch/arm64/include/asm/rwonce.h. Signed-off-by:
Will Deacon <will@kernel.org> Signed-off-by:
-
Mark Rutland authored
Currently alternative_has_cap_unlikely() can be used in VDSO code, but alternative_has_cap_likely() cannot as it references alt_cb_patch_nops, which is not available when linking the VDSO. This is unfortunate as it would be useful to have alternative_has_cap_likely() available in VDSO code. The use of alt_cb_patch_nops was added in commit: d926079f ("arm64: alternatives: add shared NOP callback") ... as removing duplicate NOPs within the kernel Image saved areasonable amount of space. Given the VDSO code will have nowhere near as many alternative branches as the main kernel image, this isn't much of a concern, and a few extra nops isn't a massive problem. Change alternative_has_cap_likely() to only use alt_cb_patch_nops for the main kernel image, and allow duplicate NOPs in VDSO code. Signed-off-by:
Mark Rutland <mark.rutland@arm.com> Signed-off-by:
-
Christophe Leroy authored
The chacha vDSO selftest doesn't check the way the counter is handled by __arch_chacha20_blocks_nostack(). It indirectly checks that the counter is writen on exit and read back on new entry, but it doesn't check that the format is correct. When implementing this function on powerpc, I missed a case where the counter was writen and read in wrong byte order. Also, the counter uses two words, but the tests with a zero counter and uses a small amount of blocks, so at the end the upper part of the counter is always 0, so it is not checked. Add a verification of counter's content in addition to the verification of the output. Also add two tests where the counter crosses the u32 upper limit. The first test verifies that the function properly writes back the upper word, the second test verifies that the function properly reads back the upper word. Signed-off-by:
-
Christophe Leroy authored
Without -O2, the generated code for testing chacha function is awful. GCC even implements rol32() as a function of 20 instructions instead of just using the rotlwi instruction. ~# time ./vdso_test_chacha TAP version 13 1..1 ok 1 chacha: PASS real 0m 37.16s user 0m 36.89s sys 0m 0.26s Several other selftests directory add -O2, and the kernel is also always built with optimisation active. Do the same for vDSO selftests. With this patch the time is reduced by approximately 15%. ~# time ./vdso_test_chacha TAP version 13 1..1 ok 1 chacha: PASS real 0m 32.09s user 0m 31.86s sys 0m 0.22s Signed-off-by:
-
Xi Ruoyao authored
Hook up the generic vDSO implementation to the LoongArch vDSO data page by providing the required __arch_chacha20_blocks_nostack, __arch_get_k_vdso_rng_data, and getrandom_syscall implementations. Also wire up the selftests. Signed-off-by:
Xi Ruoyao <xry111@xry111.site> Acked-by:
Huacai Chen <chenhuacai@kernel.org> Signed-off-by:
-
Xi Ruoyao authored
Without a prototype, we'll have to add a prototype for each architecture implementing vDSO getrandom. As most architectures will likely have the vDSO getrandom implemented in a near future, and we'd like to keep the declarations compatible everywhere (to ease the libc implementor work), we should really just have one copy of the prototype. This also is what's already done inside of include/vdso/gettime.h for those vDSO functions, so this continues that convention. Suggested-by:
-
Jason A. Donenfeld authored
Unlike the check for the standalone x86 test, the check for building the vDSO getrandom and chacaha tests looks at the architecture for the host rather than the architecture for the target when deciding if they should be built. Since the chacha test includes some assembler code this means that cross building with x86 as either the target or host is broken. There's also some additional complications, where ARCH can legitimately be either x86_64 or x86, but the source code we need to compile lives in a directory path containing arch/x86. The standard SRCARCH variable handles that. And actually, all these variables and proper substitutions are already described in tools/scripts/Makefile.arch, so just include that to handle it. Similarly, ARCH=x86 can actually describe ARCH=x86_64, just with CONFIG_64BIT, so we can't rely on ARCH for selecting non-32-bit tests. For that, check against $(ARCH)$(CONFIG_X86_32). This won't help for people manually running this inside the vDSO selftest directory (which isn't really supported anyway and has problems on various archs), but it should work for builds of the kselftests, where the CONFIG_* variables are defined. On x86_64 machines, $(ARCH)$(CONFIG_X86_32) will evaluate to x86. On arm64 machines, it will evaluate to arm64. On 32-bit x86 machines, it will evaluate to x86y, which won't match the filter list. Reported-by:
Mark Brown <broonie@kernel.org> Reported-by:
-
Christophe Leroy authored
Depending on the architecture, building a 32-bit vDSO on a 64-bit kernel is problematic when some system headers are included. Minimise the amount of headers by moving needed items, such as __{get,put}_unaligned_t, into dedicated common headers and in general use more specific headers, similar to what was done in commit 8165b57b ("linux/const.h: Extract common header for vDSO") and commit 8c59ab83 ("lib/vdso: Enable common headers"). On some architectures this results in missing PAGE_SIZE, as was described by commit 8b3843ae ("vdso/datapage: Quick fix - use asm/page-def.h for ARM64"), so define this if necessary, in the same way as done prior by commit cffaefd1 ("vdso: Use CONFIG_PAGE_SHIFT in vdso/datapage.h"). Removing linux/time64.h leads to missing 'struct timespec64' in x86's asm/pvclock.h. Add a forward declaration of that struct in that file. Signed-off-by: -
Christophe Leroy authored
With the current implementation, __cvdso_getrandom_data() calls memset() on certain architectures, which is unexpected in the VDSO. Rather than providing a memset(), simply rewrite opaque data initialization to avoid memset(). Signed-off-by:
-
Christophe Leroy authored
Same as for the gettimeofday CVDSO implementation, add c-getrandom-y to ease the inclusion of lib/vdso/getrandom.c in architectures' VDSO builds. Signed-off-by:
-
Christophe Leroy authored
_vdso_data is specific to x86 and __arch_get_k_vdso_data() is provided so that all architectures can provide the requested pointer. Do the same with _vdso_rng_data, provide __arch_get_k_vdso_rng_data() and don't use x86 _vdso_rng_data directly. Until now vdso/vsyscall.h was only included by time/vsyscall.c but now it will also be included in char/random.c, leading to a duplicate declaration of _vdso_data and _vdso_rng_data. To fix this issue, move the declaration in a C file. vma.c looks like the most appropriate candidate. We don't need to replace the definitions in vsyscall.h by declarations as declarations are already in asm/vvar.h. Signed-off-by:
-
Christophe Leroy authored
Performing SMP atomic operations on u64 fails on powerpc32: CC drivers/char/random.o In file included from <command-line>: drivers/char/random.c: In function 'crng_reseed': ././include/linux/compiler_types.h:510:45: error: call to '__compiletime_assert_391' declared with attribute error: Need native word sized stores/loads for atomicity. 510 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) | ^ ././include/linux/compiler_types.h:491:25: note: in definition of macro '__compiletime_assert' 491 | prefix ## suffix(); \ | ^~~~~~ ././include/linux/compiler_types.h:510:9: note: in expansion of macro '_compiletime_assert' 510 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) | ^~~~~~~~~~~~~~~~~~~ ././include/linux/compiler_types.h:513:9: note: in expansion of macro 'compiletime_assert' 513 | compiletime_assert(__native_word(t), \ | ^~~~~~~~~~~~~~~~~~ ./arch/powerpc/include/asm/barrier.h:74:9: note: in expansion of macro 'compiletime_assert_atomic_type' 74 | compiletime_assert_atomic_type(*p); \ | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./include/asm-generic/barrier.h:172:55: note: in expansion of macro '__smp_store_release' 172 | #define smp_store_release(p, v) do { kcsan_release(); __smp_store_release(p, v); } while (0) | ^~~~~~~~~~~~~~~~~~~ drivers/char/random.c:286:9: note: in expansion of macro 'smp_store_release' 286 | smp_store_release(&__arch_get_k_vdso_rng_data()->generation, next_gen + 1); | ^~~~~~~~~~~~~~~~~ The kernel-side generation counter in the random driver is handled as an unsigned long, not as a u64, in base_crng and struct crng. But on the vDSO side, it needs to be an u64, not just an unsigned long, in order to support a 32-bit vDSO atop a 64-bit kernel. On kernel side, however, it is an unsigned long, hence a 32-bit value on 32-bit architectures, so just cast it to unsigned long for the smp_store_release(). A side effect is that on big endian architectures the store will be performed in the upper 32 bits. It is not an issue on its own because the vDSO site doesn't mind the value, as it only checks differences. Just make sure that the vDSO side checks the full 64 bits. For that, the local current_generation has to be u64 as well. Signed-off-by:Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Jason A. Donenfeld authored
Linking to libsodium makes building this test annoying in cross compilation environments and is just way too much. Since this is just a basic correctness test, simply open code a simple, unoptimized, dumb chacha, rather than linking to libsodium. This also fixes a correctness issue on big endian systems. The kernel's random.c doesn't bother doing a le32_to_cpu operation on the random bytes that are passed as the key, and consequently neither does vgetrandom-chacha.S. However, libsodium's chacha _does_ do this, since it takes the key as an array of bytes. This meant that the test was broken on big endian systems, which this commit rectifies. Signed-off-by: -
Jason A. Donenfeld authored
Having the prototype for __arch_chacha20_blocks_nostack in arch/x86/include/asm/vdso/getrandom.h meant that the prototype and large doc comment were cloned by every architecture, which has been causing unnecessary churn. Instead move it into include/vdso/getrandom.h, where it can be shared by all archs implementing it. As a side bonus, this then lets us use that prototype in the vdso_test_chacha self test, to ensure that it matches the source, and indeed doing so turned up some inconsistencies, which are rectified here. Suggested-by:
-
Jason A. Donenfeld authored
After verifying that vDSO getrandom does work, which ensures that the RNG is initialized, test to see if it also works inside of a time namespace. This is important to test, because the vvar pages get swizzled around there. If the arch code isn't careful, the RNG will appear uninitialized inside of a time namespace. Because broken code makes the RNG appear uninitialized, test that everything works by issuing a call to vgetrandom from a fork in a time namespace, and use ptrace to ensure that the actual syscall getrandom doesn't get called. If it doesn't get called, then the test succeeds. Signed-off-by:
-
- 30 Aug, 2024 10 commits
-
-
Jason A. Donenfeld authored
When building with clang, there's this warning: vdso_test_getrandom.c:145:40: warning: omitting the parameter name in a function definition is a C23 extension [-Wc23-extensions] 145 | static void *test_vdso_getrandom(void *) | ^ vdso_test_getrandom.c:155:40: warning: omitting the parameter name in a function definition is a C23 extension [-Wc23-extensions] 155 | static void *test_libc_getrandom(void *) | ^ vdso_test_getrandom.c:165:43: warning: omitting the parameter name in a function definition is a C23 extension [-Wc23-extensions] 165 | static void *test_syscall_getrandom(void *) Add the named ctx parameter to quash it. Reported-by: -
Christophe Leroy authored
Don't duplicate parse_vdso function prototypes, include the header instead. Fixes: 693f5ca0 ("kselftest: Extend vDSO selftest") Signed-off-by:
Shuah Khan <skhan@linuxfoundation.org> Signed-off-by:
-
Christophe Leroy authored
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: c7e5789b ("kselftest: Move test_vdso to the vDSO test suite") Fixes: 2e9a9725 ("selftests: vdso: Add a selftest for vDSO getcpu()") Fixes: 693f5ca0 ("kselftest: Extend vDSO selftest") Fixes: b2f1c3db ("kselftest: Extend vdso correctness test to clock_gettime64") Fixes: 4920a259 ("selftests/vDSO: add tests for vgetrandom") Signed-off-by:
-
Christophe Leroy authored
On powerpc64, following tests fail locating vDSO functions: ~ # ./vdso_test_abi TAP version 13 1..16 # [vDSO kselftest] VDSO_VERSION: LINUX_2.6.15 # Couldn't find __kernel_gettimeofday ok 1 # SKIP __kernel_gettimeofday # clock_id: CLOCK_REALTIME # Couldn't find __kernel_clock_gettime ok 2 # SKIP __kernel_clock_gettime CLOCK_REALTIME # Couldn't find __kernel_clock_getres ok 3 # SKIP __kernel_clock_getres CLOCK_REALTIME ... # Couldn't find __kernel_time ok 16 # SKIP __kernel_time # Totals: pass:0 fail:0 xfail:0 xpass:0 skip:16 error:0 ~ # ./vdso_test_getrandom __kernel_getrandom is missing! ~ # ./vdso_test_gettimeofday Could not find __kernel_gettimeofday ~ # ./vdso_test_getcpu Could not find __kernel_getcpu On powerpc64, as shown below by readelf, vDSO functions symbols have type NOTYPE, so also accept that type when looking for symbols. $ powerpc64-linux-gnu-readelf -a arch/powerpc/kernel/vdso/vdso64.so.dbg ELF Header: Magic: 7f 45 4c 46 02 02 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, big endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: DYN (Shared object file) Machine: PowerPC64 Version: 0x1 ... Symbol table '.dynsym' contains 12 entries: Num: Value Size Type Bind Vis Ndx Name 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND 1: 0000000000000524 84 NOTYPE GLOBAL DEFAULT 8 __[...]@@LINUX_2.6.15 2: 00000000000005f0 36 NOTYPE GLOBAL DEFAULT 8 __[...]@@LINUX_2.6.15 3: 0000000000000578 68 NOTYPE GLOBAL DEFAULT 8 __[...]@@LINUX_2.6.15 4: 0000000000000000 0 OBJECT GLOBAL DEFAULT ABS LINUX_2.6.15 5: 00000000000006c0 48 NOTYPE GLOBAL DEFAULT 8 __[...]@@LINUX_2.6.15 6: 0000000000000614 172 NOTYPE GLOBAL DEFAULT 8 __[...]@@LINUX_2.6.15 7: 00000000000006f0 84 NOTYPE GLOBAL DEFAULT 8 __[...]@@LINUX_2.6.15 8: 000000000000047c 84 NOTYPE GLOBAL DEFAULT 8 __[...]@@LINUX_2.6.15 9: 0000000000000454 12 NOTYPE GLOBAL DEFAULT 8 __[...]@@LINUX_2.6.15 10: 00000000000004d0 84 NOTYPE GLOBAL DEFAULT 8 __[...]@@LINUX_2.6.15 11: 00000000000005bc 52 NOTYPE GLOBAL DEFAULT 8 __[...]@@LINUX_2.6.15 Symbol table '.symtab' contains 56 entries: Num: Value Size Type Bind Vis Ndx Name ... 45: 0000000000000000 0 OBJECT GLOBAL DEFAULT ABS LINUX_2.6.15 46: 00000000000006c0 48 NOTYPE GLOBAL DEFAULT 8 __kernel_getcpu 47: 0000000000000524 84 NOTYPE GLOBAL DEFAULT 8 __kernel_clock_getres 48: 00000000000005f0 36 NOTYPE GLOBAL DEFAULT 8 __kernel_get_tbfreq 49: 000000000000047c 84 NOTYPE GLOBAL DEFAULT 8 __kernel_gettimeofday 50: 0000000000000614 172 NOTYPE GLOBAL DEFAULT 8 __kernel_sync_dicache 51: 00000000000006f0 84 NOTYPE GLOBAL DEFAULT 8 __kernel_getrandom 52: 0000000000000454 12 NOTYPE GLOBAL DEFAULT 8 __kernel_sigtram[...] 53: 0000000000000578 68 NOTYPE GLOBAL DEFAULT 8 __kernel_time 54: 00000000000004d0 84 NOTYPE GLOBAL DEFAULT 8 __kernel_clock_g[...] 55: 00000000000005bc 52 NOTYPE GLOBAL DEFAULT 8 __kernel_get_sys[...] Fixes: 98eedc3a ("Document the vDSO and add a reference parser") Signed-off-by: -
Christophe Leroy authored
Running vdso_test_correctness on powerpc64 gives the following warning: ~ # ./vdso_test_correctness Warning: failed to find clock_gettime64 in vDSO This is because vdso_test_correctness was built with VDSO_32BIT defined. __powerpc__ macro is defined on both powerpc32 and powerpc64 so __powerpc64__ needs to be checked first in vdso_config.h Fixes: 693f5ca0 ("kselftest: Extend vDSO selftest") Signed-off-by:
-
Christophe Leroy authored
Following error occurs when running vdso_test_correctness on powerpc: ~ # ./vdso_test_correctness [WARN] failed to find vDSO [SKIP] No vDSO, so skipping clock_gettime() tests [SKIP] No vDSO, so skipping clock_gettime64() tests [RUN] Testing getcpu... [OK] CPU 0: syscall: cpu 0, node 0 On powerpc, vDSO is neither called linux-vdso.so.1 nor linux-gate.so.1 but linux-vdso32.so.1 or linux-vdso64.so.1. Also search those two names before giving up. Fixes: c7e5789b ("kselftest: Move test_vdso to the vDSO test suite") Signed-off-by:
-
Jason A. Donenfeld authored
If the getrandom test compiles for an arch, don't exit fatally if the actual cpu it's running on is unsupported. Suggested-by:
-
Xi Ruoyao authored
Building test_vdso_getrandom currently leads to following issue: In file included from /home/xry111/git-repos/linux/tools/include/linux/compiler_types.h:36, from /home/xry111/git-repos/linux/include/uapi/linux/stddef.h:5, from /home/xry111/git-repos/linux/include/uapi/linux/posix_types.h:5, from /usr/include/asm/sigcontext.h:12, from /usr/include/bits/sigcontext.h:30, from /usr/include/signal.h:301, from vdso_test_getrandom.c:14: /home/xry111/git-repos/linux/tools/include/linux/compiler-gcc.h:3:2: error: #error "Please don't include <linux/compiler-gcc.h> directly, include <linux/compiler.h> instead." 3 | #error "Please don't include <linux/compiler-gcc.h> directly, include <linux/compiler.h> instead." | ^~~~~ It's because the compiler_types.h inclusion in include/uapi/linux/stddef.h is expected to be removed by the header_install.sh script, as compiler_types.h shouldn't be used from user space. Add KHDR_INCLUDES before the existing include/uapi inclusion so that usr/include takes precedence if it's populated. Signed-off-by: -
Jason A. Donenfeld authored
CONFIG_FUNCTION_ALIGNMENT=0 is no longer necessary and BULID_VDSO wasn't spelled right while BUILD_VDSO isn't necessary, so just remove these. Reported-by:
-
Jason A. Donenfeld authored
On systems that set -Wl,--as-needed, putting the -lsodium in the wrong place on the command line means we get a linker error: CC vdso_test_chacha /usr/bin/ld: /tmp/ccKpjnSM.o: in function `main': vdso_test_chacha.c:(.text+0x276): undefined reference to `crypto_stream_chacha20' collect2: error: ld returned 1 exit status Fix this by passing pkg-config's --libs output to the LDFLAGS field instead of the CFLAGS field, as is customary. Reported-by:
-
