kernel/tools/testing/selftests/arm64/fp/Makefile, branch linux-rolling-stable

kselftest/arm64: Include kernel mode NEON in fp-stress

2024-06-12T14:50:36Z

Currently fp-stress only covers userspace use of floating point, it does not cover any kernel mode uses. Since currently kernel mode floating point usage can't be preempted and there are explicit preemption points in the existing implementations this isn't so important for fp-stress but when we readd preemption it will be good to try to exercise it. When the arm64 accelerated crypto operations are implemented we can relatively straightforwardly trigger kernel mode floating point usage by using the crypto userspace API to hash data, using the splice() support in an effort to minimise copying. We use /proc/crypto to check which accelerated implementations are available, picking the first symmetric hash we find. We run the kernel mode test unconditionally, replacing the second copy of the FPSIMD testcase for systems with FPSIMD only. If we don't think there are any suitable kernel mode implementations we fall back to running another copy of fpsimd-stress. There are a number issues with this approach, we don't actually verify that we are using an accelerated (or even CPU) implementation of the algorithm being tested and even with attempting to use splice() to minimise copying there are sizing limits on how much data gets spliced at once. Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20240521-arm64-fp-stress-kernel-v1-1-e38f107baad4@kernel.org Signed-off-by: Catalin Marinas

kselftest/arm64: Test that ptrace takes effect in the target process

2024-02-21T17:59:35Z

While we have test coverage for the ptrace interface in our selftests the current programs have a number of gaps. The testing is done per regset so does not cover interactions and at no point do any of the tests actually run the traced processes meaning that there is no validation that anything we read or write corresponds to register values the process actually sees. Let's add a new program which attempts to cover these gaps. Each test we do performs a single ptrace write. For each test we generate some random initial register data in memory and then fork() and trace a child. The child will load the generated data into the registers then trigger a breakpoint. The parent waits for the breakpoint then reads the entire child register state via ptrace, verifying that the values expected were actually loaded by the child. It then does the write being tested and resumes the child. Once resumed the child saves the register state it sees to memory and executes another breakpoint. The parent uses process_vm_readv() to get these values from the child and verifies that the values were as expected before cleaning up the child. We generate configurations with combinations of vector lengths and SVCR values and then try every ptrace write which will implement the transition we generated. In order to control execution time (especially in emulation) we only cover the minimum and maximum VL for each of SVE and SME, this will ensure we generate both increasing and decreasing changes in vector length. In order to provide a baseline test we also check the case where we resume the child without doing a ptrace write. In order to simplify the generation of the test count for kselftest we will report but skip a substantial number of tests that can't actually be expressed via a single ptrace write, several times more than we actually run. This is noisy and will add some overhead but is very much simpler so is probably worth the tradeoff. Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20240122-arm64-test-ptrace-regs-v1-1-0897f822d73e@kernel.org Signed-off-by: Catalin Marinas

kselftest/arm64: Convert za-fork to use kselftest.h

2023-04-11T20:10:51Z

Now that kselftest.h can be used with nolibc convert the za-fork test to use it. We do still have to open code ksft_print_msg() but that's not the end of the world. Some of the advantage comes from using printf() which we could have been using already. This does change the output when tests are skipped, bringing it in line with the standard kselftest output by removing the test name - we move from ok 0 skipped to ok 1 # SKIP fork_test The old output was not following KTAP format for skips, and the numbering was not standard or consistent with the reported plan. Signed-off-by: Mark Brown Signed-off-by: Shuah Khan

Merge tag 'linux-kselftest-next-6.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest

2023-02-23T17:37:29Z

Pull Kselftest update from Shuah Khan: - several patches to fix incorrect kernel headers search path from Mathieu Desnoyers - a few follow-on fixes found during testing the above change - miscellaneous fixes - support for filtering and enumerating tests * tag 'linux-kselftest-next-6.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest: (40 commits) selftests/user_events: add a note about user_events.h dependency selftests/mount_setattr: fix to make run_tests failure selftests/mount_setattr: fix redefine struct mount_attr build error selftests/sched: fix warn_unused_result build warns selftests/ptp: Remove clean target from Makefile selftests: use printf instead of echo -ne selftests/ftrace: Fix bash specific "==" operator selftests: tpm2: remove redundant ord() selftests: find echo binary to use -ne options selftests: Fix spelling mistake "allright" -> "all right" selftests: tdx: Use installed kernel headers search path selftests: ptrace: Use installed kernel headers search path selftests: memfd: Use installed kernel headers search path selftests: iommu: Use installed kernel headers search path selftests: x86: Fix incorrect kernel headers search path selftests: vm: Fix incorrect kernel headers search path selftests: user_events: Fix incorrect kernel headers search path selftests: sync: Fix incorrect kernel headers search path selftests: seccomp: Fix incorrect kernel headers search path selftests: sched: Fix incorrect kernel headers search path ...

selftests: arm64: Fix incorrect kernel headers search path

2023-01-30T22:00:39Z

Use $(KHDR_INCLUDES) as lookup path for kernel headers. This prevents building against kernel headers from the build environment in scenarios where kernel headers are installed into a specific output directory (O=...). Signed-off-by: Mathieu Desnoyers Cc: Shuah Khan Cc: linux-kselftest@vger.kernel.org Cc: Ingo Molnar Cc: # 5.18+ Acked-by: Shuah Khan Acked-by: Catalin Marinas Signed-off-by: Shuah Khan

kselftest/arm64: Add coverage of the ZT ptrace regset

2023-01-20T12:23:09Z

Add coverage of the ZT ptrace interface. Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20221208-arm64-sme2-v4-20-f2fa0aef982f@kernel.org Signed-off-by: Catalin Marinas

kselftest/arm64: Add a stress test program for ZT0

2023-01-20T12:23:07Z

Following the pattern for the other register sets add a stress test program for ZT0 which continually loads and verifies patterns in the register in an effort to discover context switching problems. Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20221208-arm64-sme2-v4-14-f2fa0aef982f@kernel.org Signed-off-by: Catalin Marinas

kselftest/arm64: kselftest harness for FP stress tests

2022-09-07T13:25:45Z

Currently the stress test programs for floating point context switching are run by hand, there are extremely simplistic harnesses which run some copies of each test individually but they are not integrated into kselftest and with SVE and SME they only run with whatever vector length the process has by default. This is hassle when running the tests and means that they're not being run at all by CI systems picking up kselftest. In order to improve our coverage and provide a more convenient interface provide a harness program which starts enough stress test programs up to cause context switching and runs them for a set period. If only FPSIMD is available in the system we start two copies of the FPSIMD stress test per CPU, otherwise we start one copy of the FPSIMD and then start the SVE, streaming SVE and ZA tests once per CPU for each available VL they have to run on. We then run for a set period monitoring for any errors reported by the test programs before cleanly terminating them. In order to provide additional coverage of signal handling and some extra noise in the scheduling we send a SIGUSR2 to the stress tests once a second, the tests will count the number of signals they get. Since kselftest is generally expected to run quickly we by default only run for ten seconds. This is enough to show if there is anything cripplingly wrong but not exactly a thorough soak test, for interactive and more focused use a command line option -t N is provided which overrides the length of time to run for (specified in seconds) and if 0 is specified then there is no timeout and the test must be manually terminated. The timeout is counted in seconds with no output, this is done to account for the potentially slow startup time for the test programs on virtual platforms which tend to struggle during startup as they are both slow and tend to support a wide range of vector lengths. Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20220829154452.824870-5-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

selftests/arm64: Clean the fp helper libraries

2022-04-28T17:00:54Z

We provide a couple of object files with helpers linked into several of the test programs, ensure they are cleaned. Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20220427181954.357975-4-broonie@kernel.org Signed-off-by: Catalin Marinas