- Linux-kselftest-mirror - lists.linaro.org

by Luis Fernandez

Good day, My name is Luis Fernandez.I would like to discuss something important that will benefit both of us. I will send you more details upon your response Regards Luis Fernandez

4 years, 1 month

1
0
0 0

[PATCH v3 0/3] kunit: allow running test suites/cases individually

by Daniel Latypov

Allow running each suite or each test case alone per kernel boot. The motivation for this is to debug "test hermeticity" issues. This new --run_isolated flag would be a good first step to try and narrow down root causes. Context: sometimes tests pass/fail depending on what ran before them. Memory corruption errors in particular might only cause noticeable issues later on. But you can also have the opposite, where "fixing" one test causes another to start failing. Usage: $ ./tools/testing/kunit/kunit.py run --kunitconfig=lib/kunit --run_isolated=suite $ ./tools/testing/kunit/kunit.py run --kunitconfig=lib/kunit --run_isolated=test $ ./tools/testing/kunit/kunit.py run --kunitconfig=lib/kunit --run_isolated=test example The last one would provide output like ======== [PASSED] example ======== [PASSED] example_simple_test ============================================================ Testing complete. 1 tests run. 0 failed. 0 crashed. 0 skipped. Starting KUnit Kernel (2/3)... ============================================================ ======== [SKIPPED] example ======== [SKIPPED] example_skip_test # SKIP this test should be skipped ============================================================ Testing complete. 1 tests run. 0 failed. 0 crashed. 1 skipped. Starting KUnit Kernel (3/3)... ============================================================ ======== [SKIPPED] example ======== [SKIPPED] example_mark_skipped_test # SKIP this test should be skipped ============================================================ Testing complete. 1 tests run. 0 failed. 0 crashed. 1 skipped. See the last patch's description for a bit more detail. Meta: The first patch is from another series with just a reworded commit message, https://lore.kernel.org/linux-kselftest/20210805235145.2528054-2-dlatypov@g… This patch series is based on Shuah's kunit branch: https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git/?… Changes: v1 -> v2: rebase onto Shuah's kunit branch, fix missing code in patch 1. v2 -> v3: fix mypy errors, drop test plan from output, fix pre-existing bug where kunit was not actually tracking test execution time (new patch 3). Daniel Latypov (4): kunit: add 'kunit.action' param to allow listing out tests kunit: tool: factor exec + parse steps into a function kunit: tool: actually track how long it took to run tests kunit: tool: support running each suite/test separately lib/kunit/executor.c | 45 ++++++++- tools/testing/kunit/kunit.py | 129 +++++++++++++++++-------- tools/testing/kunit/kunit_tool_test.py | 40 ++++++++ 3 files changed, 169 insertions(+), 45 deletions(-) base-commit: 3b29021ddd10cfb6b2565c623595bd3b02036f33 -- 2.33.0.685.g46640cef36-goog

4 years, 1 month

2
7
0 0

[PATCH v2 0/5] kunit: build kunit tests without structleak plugin

by Brendan Higgins

The structleak plugin causes the stack frame size to grow immensely when used with KUnit; this is caused because KUnit allocates lots of moderately sized structs on the stack as part of its assertion macro implementation. For most tests with small to moderately sized tests cases there are never enough KUnit assertions to be an issue at all; even when a single test cases has many KUnit assertions, the compiler should never put all these struct allocations on the stack at the same time since the scope of the structs is so limited; however, the structleak plugin does not seem to respect the compiler doing the right thing and will still warn of excessive stack size in some cases. These patches are not a permanent solution since new tests can be added with huge test cases, but this serves as a stop gap to stop structleak from being used on KUnit tests which will currently result in excessive stack size. Please see the discussion thread here[1] for more context. Changes since last revision: - Dropped mmc: sdhci-of-aspeed patch since it was not a pure test and I could not reproduce the stack size warning anyway. - Removed Wframe-larger-than=10240 warning from the bitfield kunit test. - All other patches are the same except with updated reviewers/contributor commit footers. [1] https://lore.kernel.org/linux-arm-kernel/CAFd5g44udqkDiYBWh+VeDVJ=ELXeoXwun… Arnd Bergmann (1): bitfield: build kunit tests without structleak plugin Brendan Higgins (4): gcc-plugins/structleak: add makefile var for disabling structleak iio/test-format: build kunit tests without structleak plugin device property: build kunit tests without structleak plugin thunderbolt: build kunit tests without structleak plugin drivers/base/test/Makefile | 2 +- drivers/iio/test/Makefile | 1 + drivers/thunderbolt/Makefile | 1 + lib/Makefile | 2 +- scripts/Makefile.gcc-plugins | 4 ++++ 5 files changed, 8 insertions(+), 2 deletions(-) base-commit: 02d5e016800d082058b3d3b7c3ede136cdc6ddcb -- 2.33.0.685.g46640cef36-goog

4 years, 1 month

2
6
0 0

[PATCH v1 0/6] kunit: build kunit tests without structleak plugin

by Brendan Higgins

The structleak plugin causes the stack frame size to grow immensely when used with KUnit; this is caused because KUnit allocates lots of moderately sized structs on the stack as part of its assertion macro implementation. For most tests with small to moderately sized tests cases there are never enough KUnit assertions to be an issue at all; even when a single test cases has many KUnit assertions, the compiler should never put all these struct allocations on the stack at the same time since the scope of the structs is so limited; however, the structleak plugin does not seem to respect the compiler doing the right thing and will still warn of excessive stack size in some cases. These patches are not a permanent solution since new tests can be added with huge test cases, but this serves as a stop gap to stop structleak from being used on KUnit tests which will currently result in excessive stack size. Of the following patches, I think the thunderbolt patch may be unnecessary since Linus already fixed that test. Additionally, I was not able to reproduce the error on the sdhci-of-aspeed test. Nevertheless, I included these tests cases for completeness. Please see my discussion with Arnd for more context[1]. NOTE: Arnd did the legwork for most of these patches, but did not actually share code for some of them, so I left his Signed-off-by off of those patches as I don't want to misrepresent him. Arnd, please sign off on those patches at your soonest convenience. [1] https://lore.kernel.org/linux-arm-kernel/CAFd5g44udqkDiYBWh+VeDVJ=ELXeoXwun… Arnd Bergmann (1): bitfield: build kunit tests without structleak plugin Brendan Higgins (5): gcc-plugins/structleak: add makefile var for disabling structleak iio/test-format: build kunit tests without structleak plugin device property: build kunit tests without structleak plugin thunderbolt: build kunit tests without structleak plugin mmc: sdhci-of-aspeed: build kunit tests without structleak plugin drivers/base/test/Makefile | 2 +- drivers/iio/test/Makefile | 1 + drivers/mmc/host/Makefile | 1 + drivers/thunderbolt/Makefile | 1 + lib/Makefile | 2 +- scripts/Makefile.gcc-plugins | 4 ++++ 6 files changed, 9 insertions(+), 2 deletions(-) base-commit: 316346243be6df12799c0b64b788e06bad97c30b -- 2.33.0.464.g1972c5931b-goog

4 years, 1 month

6
22
0 0

[PATCH v2 0/3] kunit: allow running test suites/cases individually

by Daniel Latypov

Allow running each suite or each test case alone per kernel boot. The motivation for this is to debug "test hermeticity" issues. This new --run_isolated flag would be a good first step to try and narrow down root causes. Context: sometimes tests pass/fail depending on what ran before them. Memory corruption errors in particular might only cause noticeable issues later on. But you can also have the opposite, where "fixing" one test causes another to start failing. Usage: $ ./tools/testing/kunit/kunit.py run --kunitconfig=lib/kunit --run_isolated=suite $ ./tools/testing/kunit/kunit.py run --kunitconfig=lib/kunit --run_isolated=test $ ./tools/testing/kunit/kunit.py run --kunitconfig=lib/kunit --run_isolated=test example The last one would provide output like ======== [PASSED] example ======== [PASSED] example_simple_test ============================================================ Testing complete. 1 tests run. 0 failed. 0 crashed. 0 skipped. Starting KUnit Kernel (2/3)... ============================================================ ======== [SKIPPED] example ======== [SKIPPED] example_skip_test # SKIP this test should be skipped ============================================================ Testing complete. 1 tests run. 0 failed. 0 crashed. 1 skipped. Starting KUnit Kernel (3/3)... ============================================================ ======== [SKIPPED] example ======== [SKIPPED] example_mark_skipped_test # SKIP this test should be skipped ============================================================ Testing complete. 1 tests run. 0 failed. 0 crashed. 1 skipped. See the last patch's description for a bit more detail. Meta: The first patch is from another series with just a reworded commit message, https://lore.kernel.org/linux-kselftest/20210805235145.2528054-2-dlatypov@g… This patch series is based on Shuah's kunit branch: https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git/?… Changes: v1 -> v2: rebase onto Shuah's kunit branch, fix missing code in patch 1. Daniel Latypov (3): kunit: add 'kunit.action' param to allow listing out tests kunit: tool: factor exec + parse steps into a function kunit: tool: support running each suite/test separately lib/kunit/executor.c | 45 ++++++++- tools/testing/kunit/kunit.py | 127 +++++++++++++++++-------- tools/testing/kunit/kunit_tool_test.py | 40 ++++++++ 3 files changed, 167 insertions(+), 45 deletions(-) base-commit: 3b29021ddd10cfb6b2565c623595bd3b02036f33 -- 2.33.0.685.g46640cef36-goog

4 years, 1 month

2
8
0 0

[PATCH 1/1] selftests: KVM: set affinity of VM to right CPUs

by Dongli Zhang

The nr_cpus = CPU_COUNT(&possible_mask) is the number of available CPUs in possible_mask. As a result, the "cpu = i % nr_cpus" may always return CPU that is not available in possible_mask. Suppose the server has 8 CPUs. The below Failure is encountered immediately if the task is bound to CPU 5 and 6. ==== Test Assertion Failure ==== rseq_test.c:228: i > (NR_TASK_MIGRATIONS / 2) pid=10127 tid=10127 errno=4 - Interrupted system call 1 0x00000000004018e5: main at rseq_test.c:227 2 0x00007fcc8fc66bf6: ?? ??:0 3 0x0000000000401959: _start at ??:? Only performed 4 KVM_RUNs, task stalled too much? Signed-off-by: Dongli Zhang <dongli.zhang(a)oracle.com> --- tools/testing/selftests/kvm/rseq_test.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/tools/testing/selftests/kvm/rseq_test.c b/tools/testing/selftests/kvm/rseq_test.c index c5e0dd664a7b..41df5173970c 100644 --- a/tools/testing/selftests/kvm/rseq_test.c +++ b/tools/testing/selftests/kvm/rseq_test.c @@ -10,6 +10,7 @@ #include <signal.h> #include <syscall.h> #include <sys/ioctl.h> +#include <sys/sysinfo.h> #include <asm/barrier.h> #include <linux/atomic.h> #include <linux/rseq.h> @@ -43,6 +44,18 @@ static bool done; static atomic_t seq_cnt; +static int get_max_cpu_idx(void) +{ + int nproc = get_nprocs_conf(); + int i, max = -ENOENT; + + for (i = 0; i < nproc; i++) + if (CPU_ISSET(i, &possible_mask)) + max = i; + + return max; +} + static void guest_code(void) { for (;;) @@ -61,10 +74,13 @@ static void *migration_worker(void *ign) { cpu_set_t allowed_mask; int r, i, nr_cpus, cpu; + int max_cpu_idx; CPU_ZERO(&allowed_mask); - nr_cpus = CPU_COUNT(&possible_mask); + max_cpu_idx = get_max_cpu_idx(); + TEST_ASSERT(max_cpu_idx >= 0, "Invalid possible_mask"); + nr_cpus = max_cpu_idx + 1; for (i = 0; i < NR_TASK_MIGRATIONS; i++) { cpu = i % nr_cpus; -- 2.17.1

4 years, 1 month

2
4
0 0

[PATCH v2 0/4] selftests: arm64: vec-syscfg updates

by Mark Brown

This series fixes up a few issues introduced into vec-syscfg during refactoring in the review process, then adds a new test which ensures that the behaviour when we attempt to set a vector length which is not supported by the current system matches what is documented in the SVE ABI documentation. v2: - Fix handling of missing VLs when checking that vector length setting works as expected. Mark Brown (4): selftests: arm64: Fix printf() format mismatch in vec-syscfg selftests: arm64: Remove bogus error check on writing to files selftests: arm64: Fix and enable test for setting current VL in vec-syscfg selftests: arm64: Verify that all possible vector lengths are handled tools/testing/selftests/arm64/fp/vec-syscfg.c | 89 ++++++++++++++++--- 1 file changed, 76 insertions(+), 13 deletions(-) base-commit: 6880fa6c56601bb8ed59df6c30fd390cc5f6dd8f -- 2.20.1

4 years, 1 month

4
12
0 0

[PATCH v3 0/4] selftests: arm64: vec-syscfg updates

by Mark Brown

This series fixes up a few issues introduced into vec-syscfg during refactoring in the review process, then adds a new test which ensures that the behaviour when we attempt to set a vector length which is not supported by the current system matches what is documented in the SVE ABI documentation. v3: - Rebased onto v5.14-rc3. - Check to see if we discovered the system vector lengths before trying to set all possible vector lengths since we need that information to validate the results. v2: - Fix handling of missing VLs when checking that vector length setting works as expected. Mark Brown (4): selftests: arm64: Fix printf() format mismatch in vec-syscfg selftests: arm64: Remove bogus error check on writing to files selftests: arm64: Fix and enable test for setting current VL in vec-syscfg selftests: arm64: Verify that all possible vector lengths are handled tools/testing/selftests/arm64/fp/vec-syscfg.c | 95 ++++++++++++++++--- 1 file changed, 82 insertions(+), 13 deletions(-) base-commit: 5816b3e6577eaa676ceb00a848f0fd65fe2adc29 -- 2.20.1

4 years, 1 month

2
5
0 0

[PATCH v1 0/8] selftests: arm64: SVE ptrace test rework

by Mark Brown

This series overhauls the selftests we have for the SVE ptrace interface to make them much more comprehensive than they are currently, making the coverage of the data read and written more complete. The new coverage for setting data on all vector lengths showed the issue with using the wrong buffer size with ptrace reported and fixed by: https://lore.kernel.org/linux-arm-kernel/20210909165356.10675-1-broonie@ker… (arm64/sve: Use correct size when reinitialising SVE state). Mark Brown (8): selftests: arm64: Use a define for the number of SVE ptrace tests to be run selftests: arm64: Don't log child creation as a test in SVE ptrace test selftests: arm64: Remove extraneous register setting code selftests: arm64: Document what the SVE ptrace test is doing selftests: arm64: Clarify output when verifying SVE register set selftests: arm64: Verify interoperation of SVE and FPSIMD register sets selftests: arm64: More comprehensively test the SVE ptrace interface selftests: arm64: Move FPSIMD in SVE ptrace test into a function tools/testing/selftests/arm64/fp/Makefile | 2 +- tools/testing/selftests/arm64/fp/TODO | 9 +- .../selftests/arm64/fp/sve-ptrace-asm.S | 33 -- tools/testing/selftests/arm64/fp/sve-ptrace.c | 460 ++++++++++++------ 4 files changed, 321 insertions(+), 183 deletions(-) delete mode 100644 tools/testing/selftests/arm64/fp/sve-ptrace-asm.S base-commit: 6880fa6c56601bb8ed59df6c30fd390cc5f6dd8f -- 2.20.1

4 years, 1 month

2
9
0 0

[PATCH v8 0/2] Interface to represent PAPR firmware attributes

by Pratik R. Sampat

RFC: https://lkml.org/lkml/2021/6/4/791 PATCH v1: https://lkml.org/lkml/2021/6/16/805 PATCH v2: https://lkml.org/lkml/2021/7/6/138 PATCH v3: https://lkml.org/lkml/2021/7/12/2799 PATCH v4: https://lkml.org/lkml/2021/7/16/532 PATCH v5: https://lkml.org/lkml/2021/7/19/247 PATCH v6: https://lkml.org/lkml/2021/7/20/36 PATCH v7: https://lkml.org/lkml/2021/7/23/26 Changelog v7-->v8 1. Rebased and tested against 5.15 2. Added a selftest to check if the energy and frequency attribues exist and their files populated Also, have implemented a POC using this interface for the powerpc-utils' ppc64_cpu --frequency command-line tool to utilize this information in userspace. The POC for the new interface has been sent to the powerpc-utils mailing list for early review: https://groups.google.com/g/powerpc-utils-devel/c/r4i7JnlyQ8s Sample output from the powerpc-utils tool is as follows: # ppc64_cpu --frequency Power and Performance Mode: XXXX Idle Power Saver Status : XXXX Processor Folding Status : XXXX --> Printed if Idle power save status is supported Platform reported frequencies --> Frequencies reported from the platform's H_CALL i.e PAPR interface min : NNNN GHz max : NNNN GHz static : NNNN GHz Tool Computed frequencies min : NNNN GHz (cpu XX) max : NNNN GHz (cpu XX) avg : NNNN GHz Pratik R. Sampat (2): powerpc/pseries: Interface to represent PAPR firmware attributes selftest/powerpc: Add PAPR sysfs attributes sniff test .../sysfs-firmware-papr-energy-scale-info | 26 ++ arch/powerpc/include/asm/hvcall.h | 24 +- arch/powerpc/kvm/trace_hv.h | 1 + arch/powerpc/platforms/pseries/Makefile | 3 +- .../pseries/papr_platform_attributes.c | 312 ++++++++++++++++++ tools/testing/selftests/powerpc/Makefile | 1 + .../powerpc/papr_attributes/.gitignore | 2 + .../powerpc/papr_attributes/Makefile | 7 + .../powerpc/papr_attributes/attr_test.c | 107 ++++++ 9 files changed, 481 insertions(+), 2 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-firmware-papr-energy-scale-info create mode 100644 arch/powerpc/platforms/pseries/papr_platform_attributes.c create mode 100644 tools/testing/selftests/powerpc/papr_attributes/.gitignore create mode 100644 tools/testing/selftests/powerpc/papr_attributes/Makefile create mode 100644 tools/testing/selftests/powerpc/papr_attributes/attr_test.c -- 2.31.1

4 years, 1 month

4
7
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror