linux-dev/tools/testing/selftests/arm64, branch linus/master

kselftest/arm64: signal: Skip SVE signal test if not enough VLs supported

2022-06-02T19:29:17Z

On platform where SVE is supported but there are less than 2 VLs available the signal SVE change test should be skipped instead of failing. Reported-by: Andre Przywara Tested-by: Andre Przywara Cc: Mark Brown Signed-off-by: Cristian Marussi Reviewed-by: Mark Brown Link: https://lore.kernel.org/r/20220524103149.2802-1-cristian.marussi@arm.com Signed-off-by: Catalin Marinas

kselftest/arm64: Explicitly build no BTI tests with BTI disabled

2022-05-16T18:43:40Z

In case a distribution enables branch protection by default do as we do for the main kernel and explicitly disable branch protection when building the test case for having BTI disabled to ensure it doesn't get turned on by the toolchain defaults. Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20220516182213.727589-1-broonie@kernel.org Signed-off-by: Catalin Marinas

kselftest/arm64: bti: force static linking

2022-05-16T18:03:14Z

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

selftests/arm64: Use switch statements in mte_common_util.c

2022-05-15T10:07:54Z

In the MTE tests there are several places where we use chains of if statements to open code what could be written as switch statements, move over to switch statements to make the idiom clearer. Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20220510164520.768783-6-broonie@kernel.org Signed-off-by: Catalin Marinas

selftests/arm64: Remove casts to/from void in check_tags_inclusion

2022-05-15T10:07:54Z

Void pointers may be freely used with other pointer types in C, any casts between void * and other pointer types serve no purpose other than to mask potential warnings. Drop such casts from check_tags_inclusion to help with future review of the code. Signed-off-by: Mark Brown Reviewed-by: Shuah Khan Link: https://lore.kernel.org/r/20220510164520.768783-5-broonie@kernel.org Signed-off-by: Catalin Marinas

selftests/arm64: Check failures to set tags in check_tags_inclusion

2022-05-15T10:07:53Z

The MTE check_tags_inclusion test uses the mte_switch_mode() helper but ignores the return values it generates meaning we might not be testing the things we're trying to test, fail the test if it reports an error. The helper will log any errors it returns. Signed-off-by: Mark Brown Reviewed-by: Shuah Khan Link: https://lore.kernel.org/r/20220510164520.768783-4-broonie@kernel.org Signed-off-by: Catalin Marinas

selftests/arm64: Allow zero tags in mte_switch_mode()

2022-05-15T10:07:53Z

mte_switch_mode() currently rejects attempts to set a zero tag however there are tests such as check_tags_inclusion which attempt to cover cases with zero tags using mte_switch_mode(). Since it is not clear why we are rejecting zero tags change the test to accept them. The issue has not previously been as apparent as it should be since the return value of mte_switch_mode() was not always checked in the callers and the tests weren't otherwise failing. Signed-off-by: Mark Brown Reviewed-by: Shuah Khan Link: https://lore.kernel.org/r/20220510164520.768783-3-broonie@kernel.org Signed-off-by: Catalin Marinas

selftests/arm64: Log errors in verify_mte_pointer_validity()

2022-05-15T10:07:53Z

When we detect a problem in verify_mte_pointer_validity() while checking tags we don't log what the problem was which makes debugging harder. Add some diagnostics. Signed-off-by: Mark Brown Reviewed-by: Shuah Khan Link: https://lore.kernel.org/r/20220510164520.768783-2-broonie@kernel.org Signed-off-by: Catalin Marinas

kselftest/arm64: Fix ABI header directory location

2022-05-04T09:02:36Z

Currently the arm64 kselftests attempt to locate the ABI headers using custom logic which doesn't work correctly in the case of out of tree builds if KBUILD_OUTPUT is not specified. Since lib.mk defines KHDR_INCLUDES with the appropriate flags we can simply remove the custom logic and use that instead. Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20220503231655.211346-1-broonie@kernel.org Signed-off-by: Catalin Marinas

selftests/arm64: Fix O= builds for the floating point tests

2022-04-28T17:00:55Z

Currently the arm64 floating point tests don't support out of tree builds due to two quirks of the kselftest build system. One is that when building a program from multiple files we shouldn't separately compile the main program to an object file as that will result in the pattern rule not matching when adjusted for the output directory. The other is that we also need to include $(OUTPUT) in the names of the binaries when specifying the dependencies in order to ensure that they get picked up with O=. Rewrite the dependencies for the executables to fix these issues. The kselftest build system will ensure OUTPUT is always defined. Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20220427181954.357975-5-broonie@kernel.org Signed-off-by: Catalin Marinas