selftests: vDSO: vdso_standalone_test_x86: Switch to nolibc

vdso_standalone_test_x86 provides its own ASM syscall wrappers and
_start() implementation. The in-tree nolibc library already provides
th

selftests: vDSO: vdso_standalone_test_x86: Switch to nolibc

vdso_standalone_test_x86 provides its own ASM syscall wrappers and
_start() implementation. The in-tree nolibc library already provides
this functionality for multiple architectures. By making use of nolibc,
the standalone testcase can be built from the exact same codebase as the
non-standalone version.

Signed-off-by: Thomas Weißschuh <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Vincenzo Frascino <[email protected]>
Acked-by: Shuah Khan <[email protected]>
Link: https://lore.kernel.org/all/[email protected]

show more ...

selftests: vDSO: parse_vdso: Use UAPI headers instead of libc headers

To allow the usage of parse_vdso.c together with a limited libc like
nolibc, use the kernels own elf.h and auxvec.h headers.

Si

selftests: vDSO: parse_vdso: Use UAPI headers instead of libc headers

To allow the usage of parse_vdso.c together with a limited libc like
nolibc, use the kernels own elf.h and auxvec.h headers.

Signed-off-by: Thomas Weißschuh <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Vincenzo Frascino <[email protected]>
Acked-by: Shuah Khan <[email protected]>
Link: https://lore.kernel.org/all/[email protected]

show more ...

selftests: vDSO: unconditionally build getrandom test

Rather than building on supported archs, build on all archs, and then
use the presence of the symbol in the vDSO to either skip the test or
move

selftests: vDSO: unconditionally build getrandom test

Rather than building on supported archs, build on all archs, and then
use the presence of the symbol in the vDSO to either skip the test or
move forward with it.

Note that this means that this test no longer checks whether the symbol
was correctly added to the kernel. But hopefully this will be clear
enough to developers and we'll cross our fingers that symbols aren't
removed by accident and not caught after this change.

Signed-off-by: Jason A. Donenfeld <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>

show more ...

selftests: vDSO: unconditionally build chacha test

Rather than using symlinks to find the vgetrandom-chacha.S file for each
arch, store this in a file that uses the compiler to determine
architectur

selftests: vDSO: unconditionally build chacha test

Rather than using symlinks to find the vgetrandom-chacha.S file for each
arch, store this in a file that uses the compiler to determine
architecture, and then make use of weak symbols to skip the test on
architectures that don't provide the code.

Signed-off-by: Jason A. Donenfeld <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>

show more ...

s390/vdso: Wire up getrandom() vdso implementation

Provide the s390 specific vdso getrandom() architecture backend.

_vdso_rng_data required data is placed within the _vdso_data vvar page,
by using

s390/vdso: Wire up getrandom() vdso implementation

Provide the s390 specific vdso getrandom() architecture backend.

_vdso_rng_data required data is placed within the _vdso_data vvar page,
by using a hardcoded offset larger than vdso_data.

As required the chacha20 implementation does not write to the stack.

The implementation follows more or less the arm64 implementations and
makes use of vector instructions. It has a fallback to the getrandom()
system call for machines where the vector facility is not installed.

The check if the vector facility is installed, as well as an
optimization for machines with the vector-enhancements facility 2, is
implemented with alternatives, avoiding runtime checks.

Note that __kernel_getrandom() is implemented without the vdso user
wrapper which would setup a stack frame for odd cases (aka very old
glibc variants) where the caller has not done that. All callers of
__kernel_getrandom() are required to setup a stack frame, like the C ABI
requires it.

The vdso testcases vdso_test_getrandom and vdso_test_chacha pass.

Benchmark on a z16:

$ ./vdso_test_getrandom bench-single
vdso: 25000000 times in 0.493703559 seconds
syscall: 25000000 times in 6.584025337 seconds

Signed-off-by: Heiko Carstens <[email protected]>
Reviewed-by: Harald Freudenberger <[email protected]>
Signed-off-by: Jason A. Donenfeld <[email protected]>

show more ...

powerpc/vdso: Wire up getrandom() vDSO implementation on VDSO32

To be consistent with other VDSO functions, the function is called
__kernel_getrandom()

__arch_chacha20_blocks_nostack() fonction is

powerpc/vdso: Wire up getrandom() vDSO implementation on VDSO32

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 <[email protected]>
Acked-by: Michael Ellerman <[email protected]>
Signed-off-by: Jason A. Donenfeld <[email protected]>

show more ...

selftests: vDSO: don't include generated headers for chacha test

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 v

selftests: vDSO: don't include generated headers for chacha test

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 <[email protected]>
Signed-off-by: Jason A. Donenfeld <[email protected]>

show more ...

arm64: vDSO: Wire up getrandom() vDSO implementation

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

arm64: vDSO: Wire up getrandom() vDSO implementation

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: Adhemerval Zanella <[email protected]>
Reviewed-by: Ard Biesheuvel <[email protected]>
Acked-by: Will Deacon <[email protected]>
Signed-off-by: Jason A. Donenfeld <[email protected]>

show more ...

selftests: vDSO: build tests with O2 optimization

Without -O2, the generated code for testing chacha function is awful.
GCC even implements rol32() as a function of 20 instructions instead of
just u

selftests: vDSO: build tests with O2 optimization

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: Christophe Leroy <[email protected]>
Signed-off-by: Jason A. Donenfeld <[email protected]>

show more ...

LoongArch: vDSO: Wire up getrandom() vDSO implementation

Hook up the generic vDSO implementation to the LoongArch vDSO data page
by providing the required __arch_chacha20_blocks_nostack,
__arch_get_

LoongArch: vDSO: Wire up getrandom() vDSO implementation

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 <[email protected]>
Acked-by: Huacai Chen <[email protected]>
Signed-off-by: Jason A. Donenfeld <[email protected]>

show more ...

selftests: vDSO: fix cross build for getrandom and chacha tests

Unlike the check for the standalone x86 test, the check for building the
vDSO getrandom and chacaha tests looks at the architecture fo

selftests: vDSO: fix cross build for getrandom and chacha tests

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 <[email protected]>
Reported-by: Christophe Leroy <[email protected]>
Signed-off-by: Jason A. Donenfeld <[email protected]>

show more ...

selftests: vDSO: open code basic chacha instead of linking to libsodium

Linking to libsodium makes building this test annoying in cross
compilation environments and is just way too much. Since this

selftests: vDSO: open code basic chacha instead of linking to libsodium

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 <[email protected]>

show more ...

selftests: vDSO: use KHDR_INCLUDES for UAPI headers for getrandom test

Building test_vdso_getrandom currently leads to following issue:

In file included from /home/xry111/git-repos/linux/tools/

selftests: vDSO: use KHDR_INCLUDES for UAPI headers for getrandom test

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: Xi Ruoyao <[email protected]>
Signed-off-by: Jason A. Donenfeld <[email protected]>

show more ...

selftests: vDSO: remove unnecessary command line defs from chacha test

CONFIG_FUNCTION_ALIGNMENT=0 is no longer necessary and BULID_VDSO wasn't
spelled right while BUILD_VDSO isn't necessary, so jus

selftests: vDSO: remove unnecessary command line defs from chacha test

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: Adhemerval Zanella Netto <[email protected]>
Signed-off-by: Jason A. Donenfeld <[email protected]>

show more ...

selftests: vDSO: separate LDLIBS from CFLAGS for libsodium

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

selftests: vDSO: separate LDLIBS from CFLAGS for libsodium

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: Adhemerval Zanella Netto <[email protected]>
Signed-off-by: Jason A. Donenfeld <[email protected]>

show more ...

selftests: vDSO: add --cflags for pkg-config command querying libsodium

When libsodium is installed into its own prefix, the --cflags output is
needed for the compiler to find libsodium headers.

Si

selftests: vDSO: add --cflags for pkg-config command querying libsodium

When libsodium is installed into its own prefix, the --cflags output is
needed for the compiler to find libsodium headers.

Signed-off-by: Xi Ruoyao <[email protected]>
Signed-off-by: Jason A. Donenfeld <[email protected]>

show more ...

selftests: vDSO: fix include order in build of test_vdso_chacha

Building test_vdso_chacha currently leads to following issue:

In file included from /home/chleroy/linux-powerpc/include/linux/limit

selftests: vDSO: fix include order in build of test_vdso_chacha

Building test_vdso_chacha currently leads to following issue:

In file included from /home/chleroy/linux-powerpc/include/linux/limits.h:7,
from /opt/powerpc64-e5500--glibc--stable-2024.02-1/powerpc64-buildroot-linux-gnu/sysroot/usr/include/bits/local_lim.h:38,
from /opt/powerpc64-e5500--glibc--stable-2024.02-1/powerpc64-buildroot-linux-gnu/sysroot/usr/include/bits/posix1_lim.h:161,
from /opt/powerpc64-e5500--glibc--stable-2024.02-1/powerpc64-buildroot-linux-gnu/sysroot/usr/include/limits.h:195,
from /opt/powerpc64-e5500--glibc--stable-2024.02-1/lib/gcc/powerpc64-buildroot-linux-gnu/12.3.0/include-fixed/limits.h:203,
from /opt/powerpc64-e5500--glibc--stable-2024.02-1/lib/gcc/powerpc64-buildroot-linux-gnu/12.3.0/include-fixed/syslimits.h:7,
from /opt/powerpc64-e5500--glibc--stable-2024.02-1/lib/gcc/powerpc64-buildroot-linux-gnu/12.3.0/include-fixed/limits.h:34,
from /tmp/sodium/usr/local/include/sodium/export.h:7,
from /tmp/sodium/usr/local/include/sodium/crypto_stream_chacha20.h:14,
from vdso_test_chacha.c:6:
/opt/powerpc64-e5500--glibc--stable-2024.02-1/powerpc64-buildroot-linux-gnu/sysroot/usr/include/bits/xopen_lim.h:99:6: error: missing binary operator before token "("
99 | # if INT_MAX == 32767
| ^~~~~~~
/opt/powerpc64-e5500--glibc--stable-2024.02-1/powerpc64-buildroot-linux-gnu/sysroot/usr/include/bits/xopen_lim.h:102:7: error: missing binary operator before token "("
102 | # if INT_MAX == 2147483647
| ^~~~~~~
/opt/powerpc64-e5500--glibc--stable-2024.02-1/powerpc64-buildroot-linux-gnu/sysroot/usr/include/bits/xopen_lim.h:126:6: error: missing binary operator before token "("
126 | # if LONG_MAX == 2147483647
| ^~~~~~~~

This is due to kernel include/linux/limits.h being included instead of
libc's limits.h.

This is because directory include/ is added through option -isystem so
it goes prior to glibc's include directory.

Replace -isystem by -idirafter.

But this implies that now tools/include/linux/linkage.h is included
instead of include/linux/linkage.h, so define a stub for
SYM_FUNC_START() and SYM_FUNC_END().

Signed-off-by: Christophe Leroy <[email protected]>
Signed-off-by: Jason A. Donenfeld <[email protected]>

show more ...

selftests: vDSO: don't hard-code location of vDSO sources

Architectures use different location for vDSO sources:

arch/mips/vdso
arch/sparc/vdso
arch/arm64/kernel/vdso
arch/riscv/kernel/vdso
ar

selftests: vDSO: don't hard-code location of vDSO sources

Architectures use different location for vDSO sources:

arch/mips/vdso
arch/sparc/vdso
arch/arm64/kernel/vdso
arch/riscv/kernel/vdso
arch/csky/kernel/vdso
arch/x86/um/vdso
arch/x86/entry/vdso
arch/powerpc/kernel/vdso
arch/arm/vdso
arch/loongarch/vdso

Don't hard-code vdso sources location in selftest Makefile. Instead
create a vdso/ symbolic link in tools/arch/$arch/ and update Makefile
accordingly.

Signed-off-by: Christophe Leroy <[email protected]>
Signed-off-by: Jason A. Donenfeld <[email protected]>

show more ...

selftests/vDSO: add tests for vgetrandom

This adds two tests for vgetrandom. The first one, vdso_test_chacha,
simply checks that the assembly implementation of chacha20 matches that
of libsodium, a

selftests/vDSO: add tests for vgetrandom

This adds two tests for vgetrandom. The first one, vdso_test_chacha,
simply checks that the assembly implementation of chacha20 matches that
of libsodium, a basic sanity check that should catch most errors. The
second, vdso_test_getrandom, is a full "libc-like" implementation of the
userspace side of vgetrandom() support. It's meant to be used also as
example code for libcs that might be integrating this.

Cc: [email protected]
Signed-off-by: Jason A. Donenfeld <[email protected]>

show more ...

selftests/vDSO: remove duplicate compiler invocations from Makefile

The Makefile open-codes compiler invocations that ../lib.mk already
provides.

Avoid this by using a Make feature that allows sett

selftests/vDSO: remove duplicate compiler invocations from Makefile

The Makefile open-codes compiler invocations that ../lib.mk already
provides.

Avoid this by using a Make feature that allows setting per-target
variables, which in this case are: CFLAGS and LDFLAGS. This approach
generates the exact same compiler invocations as before, but removes all
of the code duplication, along with the quirky mangled variable names.
So now the Makefile is smaller, less unusual, and easier to read.

The new dependencies are listed after including lib.mk, in order to
let lib.mk provide the first target ("all:"), and are grouped together
with their respective source file dependencies, for visual clarity.

Signed-off-by: John Hubbard <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>

show more ...

selftests/vDSO: remove partially duplicated "all:" target in Makefile

There were a couple of errors here:

1. TEST_GEN_PROGS was incorrectly prepending $(OUTPUT) to each program
to be built. However

selftests/vDSO: remove partially duplicated "all:" target in Makefile

There were a couple of errors here:

1. TEST_GEN_PROGS was incorrectly prepending $(OUTPUT) to each program
to be built. However, lib.mk already does that because it assumes "bare"
program names are passed in, so this ended up creating
$(OUTPUT)/$(OUTPUT)/file.c, which of course won't work as intended.

2. lib.mk was included before TEST_GEN_PROGS was set, which led to
lib.mk's "all:" target not seeing anything to rebuild.

So nothing worked, which caused the author to force things by creating
an "all:" target locally--while still including ../lib.mk.

Fix all of this by including ../lib.mk at the right place, and removing
the $(OUTPUT) prefix to the programs to be built, and removing the
duplicate "all:" target.

Reviewed-by: Muhammad Usama Anjum <[email protected]>
Signed-off-by: John Hubbard <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>

show more ...

kselftest: Move test_vdso to the vDSO test suite

Move test_vdso from x86 to the vDSO test suite.

Suggested-by: Andy Lutomirski <[email protected]>
Cc: Shuah Khan <[email protected]>
Signed-off-by: Vin

kselftest: Move test_vdso to the vDSO test suite

Move test_vdso from x86 to the vDSO test suite.

Suggested-by: Andy Lutomirski <[email protected]>
Cc: Shuah Khan <[email protected]>
Signed-off-by: Vincenzo Frascino <[email protected]>
Acked-by: Thomas Gleixner <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>

show more ...

kselftest: Extend vDSO selftest to clock_getres

The current version of the multiarch vDSO selftest verifies only
gettimeofday.

Extend the vDSO selftest to clock_getres, to verify that the
syscall a

kselftest: Extend vDSO selftest to clock_getres

The current version of the multiarch vDSO selftest verifies only
gettimeofday.

Extend the vDSO selftest to clock_getres, to verify that the
syscall and the vDSO library function return the same information.

The extension has been used to verify the hrtimer_resoltion fix.

Cc: Shuah Khan <[email protected]>
Signed-off-by: Vincenzo Frascino <[email protected]>
Acked-by: Thomas Gleixner <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>

show more ...

kselftest: Extend vDSO selftest

The current version of the multiarch vDSO selftest verifies only
gettimeofday.

Extend the vDSO selftest to the other library functions:
- time
- clock_getres
- cl

kselftest: Extend vDSO selftest

The current version of the multiarch vDSO selftest verifies only
gettimeofday.

Extend the vDSO selftest to the other library functions:
- time
- clock_getres
- clock_gettime

The extension has been used to verify the unified vdso library on the
supported architectures.

Cc: Shuah Khan <[email protected]>
Signed-off-by: Vincenzo Frascino <[email protected]>
Acked-by: Thomas Gleixner <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>

show more ...

kselftest: Enable vDSO test on non x86 platforms

Currently the vDSO tests are built only on x86 platforms and cannot be
cross compiled.

Enable vDSO TARGET for all the platforms.

Future patches wil

kselftest: Enable vDSO test on non x86 platforms

Currently the vDSO tests are built only on x86 platforms and cannot be
cross compiled.

Enable vDSO TARGET for all the platforms.

Future patches will extend the tests.

Cc: Shuah Khan <[email protected]>
Signed-off-by: Vincenzo Frascino <[email protected]>
Acked-by: Thomas Gleixner <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>

show more ...