kernel.git/tools/testing/selftests/arm64, branch linux-5.18.y

kselftest/arm64: bti: force static linking

2022-06-09T08:30:15Z

[ Upstream commit d7a49291d786b4400996afe3afcc3ef5eeb6f0ef ] The "bti" selftests are built with -nostdlib, which apparently automatically creates a statically linked binary, which is what we want and need for BTI (to avoid interactions with the dynamic linker). However this is not true when building a PIE binary, which some toolchains (Ubuntu) configure as the default. When compiling btitest with such a toolchain, it will create a dynamically linked binary, which will probably fail some tests, as the dynamic linker might not support BTI: =================== TAP version 13 1..18 not ok 1 nohint_func/call_using_br_x0 not ok 2 nohint_func/call_using_br_x16 not ok 3 nohint_func/call_using_blr .... =================== To make sure we create static binaries, add an explicit -static on the linker command line. This forces static linking even if the toolchain defaults to PIE builds, and fixes btitest runs on BTI enabled machines. Signed-off-by: Andre Przywara Reviewed-by: Mark Brown Fixes: 314bcbf09f14 ("kselftest: arm64: Add BTI tests") Link: https://lore.kernel.org/r/20220511172129.2078337-1-andre.przywara@arm.com Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin

kselftest/arm64: Log the PIDs of the parent and child in sve-ptrace

2022-03-07T21:46:57Z

If the test triggers a problem it may well result in a log message from the kernel such as a WARN() or BUG(). If these include a PID it can help with debugging to know if it was the parent or child process that triggered the issue, since the test is just creating a new thread the process name will be the same either way. Print the PIDs of the parent and child on startup so users have this information to hand should it be needed. Signed-off-by: Mark Brown Reviewed-by: Shuah Khan Link: https://lore.kernel.org/r/20220303192817.2732509-1-broonie@kernel.org Signed-off-by: Will Deacon

kselftest/arm64: signal: Allow tests to be incompatible with features

2022-02-25T14:38:29Z

Some features may invalidate some tests, for example by supporting an operation which would trap otherwise. Allow tests to list features that they are incompatible with so we can cover the case where a signal will be generated without disruption on systems where that won't happen. Signed-off-by: Mark Brown Reviewed-by: Shuah Khan Acked-by: Catalin Marinas Link: https://lore.kernel.org/r/20220207152109.197566-6-broonie@kernel.org Signed-off-by: Will Deacon

kselftest/arm64: mte: user_mem: test a wider range of values

2022-02-15T16:57:51Z

Instead of hard coding a small amount of tests, generate a wider range of tests to try catch any corner cases that could show up. These new tests test different MTE tag lengths and offsets, which previously would have caused infinite loops in the kernel. This was fixed by 295cf156231c ("arm64: Avoid premature usercopy failure"), so these are regressions tests for that corner case. Signed-off-by: Joey Gouly Cc: Catalin Marinas Cc: Will Deacon Cc: Mark Brown Cc: Shuah Khan Reviewed-by: Mark Brown Tested-by: Mark Brown Reviewed-by: Shuah Khan Reviewed-by: Catalin Marinas Link: https://lore.kernel.org/r/20220209152240.52788-7-joey.gouly@arm.com Signed-off-by: Will Deacon

kselftest/arm64: mte: user_mem: add more test types

2022-02-15T16:57:50Z

To expand the test coverage for MTE tags in userspace memory, also perform the test with `write`, `readv` and `writev` syscalls. Signed-off-by: Joey Gouly Cc: Catalin Marinas Cc: Will Deacon Cc: Mark Brown Cc: Shuah Khan Reviewed-by: Mark Brown Tested-by: Mark Brown Reviewed-by: Shuah Khan Reviewed-by: Catalin Marinas Link: https://lore.kernel.org/r/20220209152240.52788-6-joey.gouly@arm.com Signed-off-by: Will Deacon

kselftest/arm64: mte: user_mem: add test type enum

2022-02-15T16:57:50Z

The test is currently hardcoded to use the `read` syscall, this commit adds a test_type enum to support expanding the test coverage to other syscalls. Signed-off-by: Joey Gouly Cc: Catalin Marinas Cc: Will Deacon Cc: Mark Brown Cc: Shuah Khan Reviewed-by: Mark Brown Tested-by: Mark Brown Reviewed-by: Shuah Khan Reviewed-by: Catalin Marinas Link: https://lore.kernel.org/r/20220209152240.52788-5-joey.gouly@arm.com Signed-off-by: Will Deacon

kselftest/arm64: mte: user_mem: check different offsets and sizes

2022-02-15T16:57:50Z

To check there are no assumptions in the kernel about buffer sizes or alignments of user space pointers, expand the test to cover different sizes and offsets. Signed-off-by: Joey Gouly Cc: Catalin Marinas Cc: Will Deacon Cc: Mark Brown Cc: Shuah Khan Reviewed-by: Mark Brown Tested-by: Mark Brown Reviewed-by: Shuah Khan Reviewed-by: Catalin Marinas Link: https://lore.kernel.org/r/20220209152240.52788-4-joey.gouly@arm.com Signed-off-by: Will Deacon

kselftest/arm64: mte: user_mem: rework error handling

2022-02-15T16:57:50Z

Future commits will have multiple iterations of tests in this function, so make the error handling assume it will pass and then bail out if there is an error. Signed-off-by: Joey Gouly Cc: Catalin Marinas Cc: Will Deacon Cc: Mark Brown Cc: Shuah Khan Reviewed-by: Mark Brown Tested-by: Mark Brown Reviewed-by: Shuah Khan Reviewed-by: Catalin Marinas Link: https://lore.kernel.org/r/20220209152240.52788-3-joey.gouly@arm.com Signed-off-by: Will Deacon

kselftest/arm64: mte: user_mem: introduce tag_offset and tag_len

2022-02-15T16:57:50Z

These can be used to place an MTE tag at an address that is not at a page size boundary. The kernel prior to 295cf156231c ("arm64: Avoid premature usercopy failure"), would infinite loop if an MTE tag was placed not at a PAGE_SIZE boundary. This is because the kernel checked if the pages were readable by checking the first byte of each page, but would then fault in the middle of the page due to the MTE tag. Signed-off-by: Joey Gouly Cc: Catalin Marinas Cc: Will Deacon Cc: Mark Brown Cc: Shuah Khan Reviewed-by: Mark Brown Tested-by: Mark Brown Reviewed-by: Shuah Khan Reviewed-by: Catalin Marinas Link: https://lore.kernel.org/r/20220209152240.52788-2-joey.gouly@arm.com Signed-off-by: Will Deacon

kselftest/arm64: Remove local definitions of MTE prctls

2022-02-15T15:59:20Z

The GCR EL1 test unconditionally includes local definitions of the prctls it tests. Since not only will the kselftest build infrastructure ensure that the in tree uapi headers are available but the toolchain being used to build kselftest may ensure that system uapi headers with MTE support are available this causes the compiler to warn about duplicate definitions. Remove these duplicate definitions. Signed-off-by: Mark Brown Acked-by: Catalin Marinas Acked-by: Shuah Khan Link: https://lore.kernel.org/r/20220126174421.1712795-1-broonie@kernel.org Signed-off-by: Will Deacon