October 2021 - Linux-kselftest-mirror

[REGRESSION] lkft kselftest for next-20211013

by lkft＠linaro.org

## Build * kernel: 5.15.0-rc5 * git: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next * git branch: master * git commit: 8006b911c90a4ec09958447d24c8a4c3538f5723 * git describe: next-20211013 * test details: https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20211013 ## Regressions (compared to next-20211007) * x86, kselftest-kvm - kvm.vmx_preemption_timer_test Reported-by: Linux Kernel Functional Testing <lkft(a)linaro.org> ## Fixes (compared to next-20211007) No fixes found. ## Test result summary total: 3126, pass: 1889, fail: 242, skip: 995, xfail: 0 ## Build Summary ## Test suites summary * kselftest-android * kselftest-arm64 * kselftest-arm64/arm64.btitest.bti_c_func * kselftest-arm64/arm64.btitest.bti_j_func * kselftest-arm64/arm64.btitest.bti_jc_func * kselftest-arm64/arm64.btitest.bti_none_func * kselftest-arm64/arm64.btitest.nohint_func * kselftest-arm64/arm64.btitest.paciasp_func * kselftest-arm64/arm64.nobtitest.bti_c_func * kselftest-arm64/arm64.nobtitest.bti_j_func * kselftest-arm64/arm64.nobtitest.bti_jc_func * kselftest-arm64/arm64.nobtitest.bti_none_func * kselftest-arm64/arm64.nobtitest.nohint_func * kselftest-arm64/arm64.nobtitest.paciasp_func * kselftest-bpf * kselftest-breakpoints * kselftest-capabilities * kselftest-cgroup * kselftest-clone3 * kselftest-core * kselftest-cpu-hotplug * kselftest-cpufreq * kselftest-drivers * kselftest-efivarfs * kselftest-filesystems * kselftest-firmware * kselftest-fpu * kselftest-futex * kselftest-gpio * kselftest-intel_pstate * kselftest-ipc * kselftest-ir * kselftest-kcmp * kselftest-kexec * kselftest-kvm * kselftest-lib * kselftest-livepatch * kselftest-lkdtm * kselftest-membarrier * kselftest-net * kselftest-netfilter * kselftest-nsfs * kselftest-openat2 * kselftest-pid_namespace * kselftest-pidfd * kselftest-proc * kselftest-pstore * kselftest-ptrace * kselftest-rseq * kselftest-rtc * kselftest-seccomp * kselftest-sigaltstack * kselftest-size * kselftest-splice * kselftest-static_keys * kselftest-sync * kselftest-sysctl * kselftest-tc-testing * kselftest-timens * kselftest-timers * kselftest-tmpfs * kselftest-tpm2 * kselftest-user * kselftest-vm * kselftest-x86 * kselftest-zram -- Linaro LKFT https://lkft.linaro.org

3 years, 2 months

1
0
0 0

lkft kselftest for next-20211012

by lkft＠linaro.org

## Build * kernel: 5.15.0-rc5 * git: ['https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git', 'https://gitlab.com/Linaro/lkft/mirrors/next/linux-next'] * git branch: master * git commit: 6d3d22efa090e7a5d3691613297aab12c6d2708a * git describe: next-20211012 * test details: https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20211012 ## Regressions (compared to next-20211007) No regressions found. Tested-by: Linux Kernel Functional Testing <lkft(a)linaro.org> ## Fixes (compared to next-20211007) No fixes found. ## Test result summary total: 2849, pass: 1736, fail: 238, skip: 875, xfail: 0 ## Build Summary ## Test suites summary * kselftest-android * kselftest-arm64 * kselftest-arm64/arm64.btitest.bti_c_func * kselftest-arm64/arm64.btitest.bti_j_func * kselftest-arm64/arm64.btitest.bti_jc_func * kselftest-arm64/arm64.btitest.bti_none_func * kselftest-arm64/arm64.btitest.nohint_func * kselftest-arm64/arm64.btitest.paciasp_func * kselftest-arm64/arm64.nobtitest.bti_c_func * kselftest-arm64/arm64.nobtitest.bti_j_func * kselftest-arm64/arm64.nobtitest.bti_jc_func * kselftest-arm64/arm64.nobtitest.bti_none_func * kselftest-arm64/arm64.nobtitest.nohint_func * kselftest-arm64/arm64.nobtitest.paciasp_func * kselftest-bpf * kselftest-breakpoints * kselftest-capabilities * kselftest-cgroup * kselftest-clone3 * kselftest-core * kselftest-cpu-hotplug * kselftest-cpufreq * kselftest-drivers * kselftest-efivarfs * kselftest-filesystems * kselftest-firmware * kselftest-fpu * kselftest-futex * kselftest-gpio * kselftest-intel_pstate * kselftest-ipc * kselftest-ir * kselftest-kcmp * kselftest-kexec * kselftest-kvm * kselftest-lib * kselftest-livepatch * kselftest-lkdtm * kselftest-membarrier * kselftest-net * kselftest-netfilter * kselftest-nsfs * kselftest-openat2 * kselftest-pid_namespace * kselftest-pidfd * kselftest-proc * kselftest-pstore * kselftest-ptrace * kselftest-rseq * kselftest-rtc * kselftest-seccomp * kselftest-sigaltstack * kselftest-size * kselftest-splice * kselftest-static_keys * kselftest-sync * kselftest-sysctl * kselftest-tc-testing * kselftest-timens * kselftest-timers * kselftest-tmpfs * kselftest-tpm2 * kselftest-user * kselftest-vm * kselftest-x86 * kselftest-zram -- Linaro LKFT https://lkft.linaro.org

3 years, 2 months

1
0
0 0

[REGRESSION] lkft kselftest for next-20211011

by lkft＠linaro.org

## Build * kernel: 5.15.0-rc4 * git: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next * git branch: master * git commit: d3134eb5de8546a214c028fb7195e764b89da7d4 * git describe: next-20211011 * test details: https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20211011 ## Regressions (compared to next-20211006) * hi6220-hikey, kselftest-timers - timers.nsleep-lat - timers.set-timer-lat * qemu_i386, kselftest-pidfd - pidfd.pidfd_test * qemu_x86_64, kselftest-pidfd - pidfd.pidfd_test Reported-by: Linux Kernel Functional Testing <lkft(a)linaro.org> ## Fixes (compared to next-20211006) * dragonboard-410c, kselftest-gpio - gpio.gpio-mockup.sh * qemu_i386, kselftest-gpio - gpio.gpio-mockup.sh * qemu_i386, kselftest-seccomp - seccomp.seccomp_benchmark * qemu_x86_64, kselftest-seccomp - seccomp.seccomp_benchmark * x86, kselftest-lkdtm - lkdtm.SLAB_FREE_DOUBLE.sh ## Test result summary total: 2802, pass: 1736, fail: 237, skip: 829, xfail: 0 ## Build Summary ## Test suites summary * kselftest-android * kselftest-bpf * kselftest-breakpoints * kselftest-capabilities * kselftest-cgroup * kselftest-clone3 * kselftest-core * kselftest-cpu-hotplug * kselftest-cpufreq * kselftest-drivers * kselftest-efivarfs * kselftest-filesystems * kselftest-firmware * kselftest-fpu * kselftest-futex * kselftest-gpio * kselftest-intel_pstate * kselftest-ipc * kselftest-ir * kselftest-kcmp * kselftest-kexec * kselftest-kvm * kselftest-lib * kselftest-livepatch * kselftest-lkdtm * kselftest-membarrier * kselftest-net * kselftest-netfilter * kselftest-nsfs * kselftest-openat2 * kselftest-pid_namespace * kselftest-pidfd * kselftest-proc * kselftest-pstore * kselftest-ptrace * kselftest-rseq * kselftest-rtc * kselftest-seccomp * kselftest-sigaltstack * kselftest-size * kselftest-splice * kselftest-static_keys * kselftest-sync * kselftest-sysctl * kselftest-tc-testing * kselftest-timens * kselftest-timers * kselftest-tmpfs * kselftest-tpm2 * kselftest-user * kselftest-vm * kselftest-x86 * kselftest-zram -- Linaro LKFT https://lkft.linaro.org

3 years, 2 months

1
0
0 0

[REGRESSION] lkft kselftest for next-20211008

by lkft＠linaro.org

## Build * kernel: 5.15.0-rc4 * git: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next * git branch: master * git commit: 683f29b781aeaab6bf302eeb2ef08a5e5f9d8a27 * git describe: next-20211008 * test details: https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20211008 ## Regressions (compared to next-20211006) * qemu_x86_64, kselftest-pidfd - pidfd.pidfd_test * x86, kselftest-kvm - kvm.hyperv_clock Reported-by: Linux Kernel Functional Testing <lkft(a)linaro.org> ## Fixes (compared to next-20211006) * dragonboard-410c, kselftest-gpio - gpio.gpio-mockup.sh * hi6220-hikey, kselftest-proc - proc.proc-uptime-001 * qemu_x86_64, kselftest-seccomp - seccomp.seccomp_benchmark * x86, kselftest-lkdtm - lkdtm.SLAB_FREE_DOUBLE.sh ## Test result summary total: 1652, pass: 1005, fail: 105, skip: 542, xfail: 0 ## Build Summary ## Test suites summary * kselftest-android * kselftest-arm64 * kselftest-arm64/arm64.btitest.bti_c_func * kselftest-arm64/arm64.btitest.bti_j_func * kselftest-arm64/arm64.btitest.bti_jc_func * kselftest-arm64/arm64.btitest.bti_none_func * kselftest-arm64/arm64.btitest.nohint_func * kselftest-arm64/arm64.btitest.paciasp_func * kselftest-arm64/arm64.nobtitest.bti_c_func * kselftest-arm64/arm64.nobtitest.bti_j_func * kselftest-arm64/arm64.nobtitest.bti_jc_func * kselftest-arm64/arm64.nobtitest.bti_none_func * kselftest-arm64/arm64.nobtitest.nohint_func * kselftest-arm64/arm64.nobtitest.paciasp_func * kselftest-bpf * kselftest-breakpoints * kselftest-capabilities * kselftest-cgroup * kselftest-clone3 * kselftest-core * kselftest-cpu-hotplug * kselftest-cpufreq * kselftest-drivers * kselftest-efivarfs * kselftest-filesystems * kselftest-firmware * kselftest-fpu * kselftest-futex * kselftest-gpio * kselftest-intel_pstate * kselftest-ipc * kselftest-ir * kselftest-kcmp * kselftest-kexec * kselftest-kvm * kselftest-lib * kselftest-livepatch * kselftest-lkdtm * kselftest-membarrier * kselftest-net * kselftest-netfilter * kselftest-nsfs * kselftest-openat2 * kselftest-pid_namespace * kselftest-pidfd * kselftest-proc * kselftest-pstore * kselftest-ptrace * kselftest-rseq * kselftest-rtc * kselftest-seccomp * kselftest-sigaltstack * kselftest-size * kselftest-splice * kselftest-static_keys * kselftest-sync * kselftest-sysctl * kselftest-tc-testing * kselftest-timens * kselftest-timers * kselftest-tmpfs * kselftest-tpm2 * kselftest-user * kselftest-vm * kselftest-x86 * kselftest-zram -- Linaro LKFT https://lkft.linaro.org

3 years, 2 months

1
0
0 0

[RFC][PATCH] selftests/vm/transhuge-stress: fix ram size thinko

by George G. Davis

From: "George G. Davis" <davis.george(a)siemens.com> When executing transhuge-stress with an argument to specify the virtual memory size for testing, the ram size is reported as 0, e.g. transhuge-stress 384 thp-mmap: allocate 192 transhuge pages, using 384 MiB virtual memory and 0 MiB of ram thp-mmap: 0.184 s/loop, 0.957 ms/page, 2090.265 MiB/s 192 succeed, 0 failed This appears to be due to a thinko in commit 0085d61fe05e ("selftests/vm/transhuge-stress: stress test for memory compaction"), where, at a guess, the intent was to base "xyz MiB of ram" on `ram` size. Here are results after using `ram` size: thp-mmap: allocate 192 transhuge pages, using 384 MiB virtual memory and 14 MiB of ram Fixes: 0085d61fe05e ("selftests/vm/transhuge-stress: stress test for memory compaction") Signed-off-by: George G. Davis <davis.george(a)siemens.com> --- tools/testing/selftests/vm/transhuge-stress.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/vm/transhuge-stress.c b/tools/testing/selftests/vm/transhuge-stress.c index fd7f1b4a96f9..5e4c036f6ad3 100644 --- a/tools/testing/selftests/vm/transhuge-stress.c +++ b/tools/testing/selftests/vm/transhuge-stress.c @@ -79,7 +79,7 @@ int main(int argc, char **argv) warnx("allocate %zd transhuge pages, using %zd MiB virtual memory" " and %zd MiB of ram", len >> HPAGE_SHIFT, len >> 20, - len >> (20 + HPAGE_SHIFT - PAGE_SHIFT - 1)); + ram >> (20 + HPAGE_SHIFT - PAGE_SHIFT - 1)); pagemap_fd = open("/proc/self/pagemap", O_RDONLY); if (pagemap_fd < 0) -- 2.17.1

3 years, 2 months

3
3
0 0

[PATCH v1] selftests/vm: make MADV_POPULATE_(READ|WRITE) use in-tree headers

by David Hildenbrand

The madv_populate selftest currently builds with a warning when the local installed headers (via the distribution) don't include MADV_POPULATE_READ and MADV_POPULATE_WRITE. The warning is correct, because the test cannot locate the necessary header. Reason is that the in-tree installed headers (usr/include) have a "linux" instead of a "sys" subdirectory. Including "linux/mman.h" instead of "sys/mman.h" doesn't work (e.g., mmap() and madvise() are not defined that way). The only thing that seems to work is including "linux/mman.h" in addition to "sys/mman.h". We can get rid of our availability check and simplify. Reported-by: Shuah Khan <skhan(a)linuxfoundation.org> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: linux-mm(a)kvack.org Cc: linux-kselftest(a)vger.kernel.org Signed-off-by: David Hildenbrand <david(a)redhat.com> --- tools/testing/selftests/vm/madv_populate.c | 15 +-------------- 1 file changed, 1 insertion(+), 14 deletions(-) diff --git a/tools/testing/selftests/vm/madv_populate.c b/tools/testing/selftests/vm/madv_populate.c index b959e4ebdad4..3ee0e8275600 100644 --- a/tools/testing/selftests/vm/madv_populate.c +++ b/tools/testing/selftests/vm/madv_populate.c @@ -14,12 +14,11 @@ #include <unistd.h> #include <errno.h> #include <fcntl.h> +#include <linux/mman.h> #include <sys/mman.h> #include "../kselftest.h" -#if defined(MADV_POPULATE_READ) && defined(MADV_POPULATE_WRITE) - /* * For now, we're using 2 MiB of private anonymous memory for all tests. */ @@ -328,15 +327,3 @@ int main(int argc, char **argv) err, ksft_test_num()); return ksft_exit_pass(); } - -#else /* defined(MADV_POPULATE_READ) && defined(MADV_POPULATE_WRITE) */ - -#warning "missing MADV_POPULATE_READ or MADV_POPULATE_WRITE definition" - -int main(int argc, char **argv) -{ - ksft_print_header(); - ksft_exit_skip("MADV_POPULATE_READ or MADV_POPULATE_WRITE not defined\n"); -} - -#endif /* defined(MADV_POPULATE_READ) && defined(MADV_POPULATE_WRITE) */ -- 2.31.1

3 years, 2 months

1
0
0 0

selftests/vm madv_populate.c test

by Shuah Khan

Hi David, I am running into the following warning when try to build this test: madv_populate.c:334:2: warning: #warning "missing MADV_POPULATE_READ or MADV_POPULATE_WRITE definition" [-Wcpp] 334 | #warning "missing MADV_POPULATE_READ or MADV_POPULATE_WRITE definition" | ^~~~~~~ I see that the following handling is in place. However there is no other information to explain why the check is necessary. #if defined(MADV_POPULATE_READ) && defined(MADV_POPULATE_WRITE) #else /* defined(MADV_POPULATE_READ) && defined(MADV_POPULATE_WRITE) */ #warning "missing MADV_POPULATE_READ or MADV_POPULATE_WRITE definition" I do see these defined in: include/uapi/asm-generic/mman-common.h:#define MADV_POPULATE_READ 22 include/uapi/asm-generic/mman-common.h:#define MADV_POPULATE_WRITE 23 Is this the case of missing include from madv_populate.c? thanks, -- Shuah

3 years, 2 months

2
12
0 0

[PATCH v1 00/38] arm64/sme: Initial support for the Scalable Matrix Extension

by Mark Brown

This series provides initial support for the ARMv9 Scalable Matrix Extension (SME). SME takes the approach used for vectors in SVE and extends this to provide architectural support for matrix operations. A more detailed overview can be found in [1]. For the kernel SME can be thought of as a series of features which are intended to be used together by applications but operate mostly orthogonally: - The ZA matrix register. - Streaming mode, in which ZA can be accessed and a subset of SVE features are available. - A second vector length, used for streaming mode SVE and ZA and controlled using a similar interface to that for SVE. - TPIDR2, a new userspace controllable system register intended for use by the C library for storing context related to the ZA ABI. A substantial part of the series is dedicated to refactoring the existing SVE support so that we don't need to duplicate code for handling vector lengths and the SVE registers, this involves creating an array of vector types and making the users take the vector type as a parameter. I'm not 100% happy with this but wasn't able to come up with anything better, duplicating code definitely felt like a bad idea so this felt like the least bad thing. If this approach makes sense to people it might make sense to split this off into a separate series and/or merge it while the rest is pending review to try to make things a little more digestable, the series is very large so it'd probably make things easier to digest if some of the preparatory refactoring could be merged before the rest is ready. One feature of the architecture of particular note is that switching to and from streaming mode may change the size of and invalidate the contents of the SVE registers, and when in streaming mode the FFR is not accessible. This complicates aspects of the ABI like signal handling and ptrace. This initial implementation is mainly intended to get the ABI in place, there are several areas which will be worked on going forwards - some of these will be blockers, others could be handled in followup serieses: - KVM is not currently supported and we depend on !KVM, in hopefully the next version I will add support for coexisting with KVM and then in a subsequent series implement real support for KVM guests. - It is likely some build configurations have issues, I've not fully checked this yet. In general testing is still ongoing, I anticipate finding and fixing some issues in the implementation. - No support is currently provided for scheduler control of SME or SME applications, given the size of the SME register state the context switch overhead may be noticable so this may be needed especially for real time applications. Similar concerns already exist for larger SVE vector lengths but are amplified for SME, particularly as the vector length increases. - There has been no work on optimising the performance of anything the kernel does. It is not expected that any systems will be encountered that support SME but not SVE, SME is an ARMv9 feature and SVE is mandatory for ARMv9. The code attempts to handle any such systems that are encountered but this hasn't been tested extensively. Due to dependencies on kselftest changes already upstreamed this series is based on for-next/kselftest in the arm64 tree. [1] https://community.arm.com/developer/ip-products/processors/b/processors-ip-… Mark Brown (38): arm64/fp: Reindent fpsimd_save() arm64/sve: Remove sve_load_from_fpsimd_state() arm64/sve: Make access to FFR optional arm64/sve: Rename find_supported_vector_length() arm64/sve: Use accessor functions for vector lengths in thread_struct arm64/sve: Put system wide vector length information into structs arm64/sve: Explicitly load vector length when restoring SVE state arm64/sve: Track vector lengths for tasks in an array arm64/sve: Make sysctl interface for SVE reusable by SME arm64/sve: Generalise vector length configuration prctl() for SME selftests: arm64: Parameterise ptrace vector length information arm64/sme: Provide ABI documentation for SME arm64/sme: System register and exception syndrome definitions arm64/sme: Define macros for manually encoding SME instructions arm64/sme: Early CPU setup for SME arm64/sme: Basic enumeration support arm64/sme: Identify supported SME vector lengths at boot arm64/sme: Implement sysctl to set the default vector length arm64/sme: Implement vector length configuration prctl()s arm64/sme: Implement support for TPIDR2 arm64/sme: Implement SVCR context switching arm64/sme: Implement streaming SVE context switching arm64/sme: Implement ZA context switching arm64/sme: Implement traps and syscall handling for SME arm64/sme: Implement streaming SVE signal handling arm64/sme: Implement ZA signal handling arm64/sme: Implement ptrace support for streaming mode SVE registers arm64/sme: Add ptrace support for ZA arm64/sme: Disable streaming mode and ZA when flushing CPU state arm64/sme: Save and restore streaming mode over EFI runtime calls arm64/sme: Provide Kconfig for SME kselftest/arm64: Add tests for TPIDR2 kselftest/arm64: Extend vector configuration API tests to cover SME kselftest/arm64: sme: Provide streaming mode SVE stress test kselftest/arm64: Add stress test for SME ZA context switching kselftest/arm64: signal: Add SME signal handling tests selftests: arm64: Add streaming SVE to SVE ptrace tests selftests: arm64: Add coverage for the ZA ptrace interface Documentation/arm64/elf_hwcaps.rst | 29 + Documentation/arm64/index.rst | 1 + Documentation/arm64/sme.rst | 427 +++++++++ Documentation/arm64/sve.rst | 62 +- arch/arm64/Kconfig | 11 + arch/arm64/include/asm/cpu.h | 4 + arch/arm64/include/asm/cpufeature.h | 18 + arch/arm64/include/asm/el2_setup.h | 36 + arch/arm64/include/asm/esr.h | 3 +- arch/arm64/include/asm/exception.h | 1 + arch/arm64/include/asm/fpsimd.h | 178 +++- arch/arm64/include/asm/fpsimdmacros.h | 94 +- arch/arm64/include/asm/hwcap.h | 7 + arch/arm64/include/asm/kvm_arm.h | 1 + arch/arm64/include/asm/processor.h | 67 +- arch/arm64/include/asm/sysreg.h | 53 ++ arch/arm64/include/asm/thread_info.h | 4 +- arch/arm64/include/uapi/asm/hwcap.h | 7 + arch/arm64/include/uapi/asm/ptrace.h | 69 +- arch/arm64/include/uapi/asm/sigcontext.h | 55 +- arch/arm64/kernel/cpufeature.c | 96 +- arch/arm64/kernel/cpuinfo.c | 12 + arch/arm64/kernel/entry-common.c | 10 + arch/arm64/kernel/entry-fpsimd.S | 63 +- arch/arm64/kernel/fpsimd.c | 900 ++++++++++++++---- arch/arm64/kernel/process.c | 19 +- arch/arm64/kernel/ptrace.c | 358 ++++++- arch/arm64/kernel/signal.c | 189 +++- arch/arm64/kernel/syscall.c | 49 +- arch/arm64/kernel/traps.c | 1 + arch/arm64/kvm/fpsimd.c | 3 +- arch/arm64/kvm/hyp/fpsimd.S | 6 +- arch/arm64/kvm/reset.c | 14 +- arch/arm64/tools/cpucaps | 1 + include/uapi/linux/elf.h | 2 + include/uapi/linux/prctl.h | 9 + kernel/sys.c | 6 + tools/testing/selftests/arm64/Makefile | 2 +- tools/testing/selftests/arm64/abi/.gitignore | 1 + tools/testing/selftests/arm64/abi/Makefile | 13 + tools/testing/selftests/arm64/abi/tpidr2.c | 204 ++++ tools/testing/selftests/arm64/fp/.gitignore | 4 + tools/testing/selftests/arm64/fp/Makefile | 12 +- tools/testing/selftests/arm64/fp/rdvl-sme.c | 14 + tools/testing/selftests/arm64/fp/rdvl.S | 16 + tools/testing/selftests/arm64/fp/rdvl.h | 1 + tools/testing/selftests/arm64/fp/ssve-stress | 59 ++ tools/testing/selftests/arm64/fp/sve-ptrace.c | 203 ++-- tools/testing/selftests/arm64/fp/sve-test.S | 30 + tools/testing/selftests/arm64/fp/vec-syscfg.c | 10 + tools/testing/selftests/arm64/fp/za-ptrace.c | 353 +++++++ tools/testing/selftests/arm64/fp/za-stress | 59 ++ tools/testing/selftests/arm64/fp/za-test.S | 545 +++++++++++ .../testing/selftests/arm64/signal/.gitignore | 2 + .../selftests/arm64/signal/test_signals.h | 2 + .../arm64/signal/test_signals_utils.c | 3 + .../testcases/fake_sigreturn_sme_change_vl.c | 92 ++ .../selftests/arm64/signal/testcases/sme_vl.c | 70 ++ .../arm64/signal/testcases/ssve_regs.c | 129 +++ 59 files changed, 4293 insertions(+), 396 deletions(-) create mode 100644 Documentation/arm64/sme.rst create mode 100644 tools/testing/selftests/arm64/abi/.gitignore create mode 100644 tools/testing/selftests/arm64/abi/Makefile create mode 100644 tools/testing/selftests/arm64/abi/tpidr2.c create mode 100644 tools/testing/selftests/arm64/fp/rdvl-sme.c create mode 100644 tools/testing/selftests/arm64/fp/ssve-stress create mode 100644 tools/testing/selftests/arm64/fp/za-ptrace.c create mode 100644 tools/testing/selftests/arm64/fp/za-stress create mode 100644 tools/testing/selftests/arm64/fp/za-test.S create mode 100644 tools/testing/selftests/arm64/signal/testcases/fake_sigreturn_sme_change_vl.c create mode 100644 tools/testing/selftests/arm64/signal/testcases/sme_vl.c create mode 100644 tools/testing/selftests/arm64/signal/testcases/ssve_regs.c base-commit: 8694e5e6388695195a32bd5746635ca166a8df56 -- 2.20.1

3 years, 2 months

6
68
0 0

[PATCH] selftests/ftrace: Stop tracing before searching non-exist event entry

by Masami Hiramatsu

Stop tracing before searching the pattern which is expected to not exist on the trace buffer. In some case, it will take too long and may not come back eternally because while searching the tracing data will be increased by the searching activity. I found this with enabling kernel debug options, like kmemleak, lockdep etc. and run it on qemu with 2 CPUs. It did not come back in 20 minutes and finally I need to interrupt it to stop. Signed-off-by: Masami Hiramatsu <mhiramat(a)kernel.org> --- .../ftrace/test.d/ftrace/func_profiler.tc | 3 +++ 1 file changed, 3 insertions(+) diff --git a/tools/testing/selftests/ftrace/test.d/ftrace/func_profiler.tc b/tools/testing/selftests/ftrace/test.d/ftrace/func_profiler.tc index 1dbd766c0cd2..440f4d87aa4b 100644 --- a/tools/testing/selftests/ftrace/test.d/ftrace/func_profiler.tc +++ b/tools/testing/selftests/ftrace/test.d/ftrace/func_profiler.tc @@ -56,6 +56,9 @@ clear_trace sleep 1 echo "make sure something other than scheduler is being traced" + +echo 0 > tracing_on + if ! grep -v -e '^#' -e 'schedule' trace > /dev/null; then cat trace fail "no other functions besides schedule was found"

3 years, 2 months

2
1
0 0

Re: [PATCH v7 5/6] cgroup/cpuset: Update description of cpuset.cpus.partition in cgroup-v2.rst

by Michal Koutný

On Wed, Oct 06, 2021 at 02:21:03PM -0400, Waiman Long <llong(a)redhat.com> wrote: > Sorry for not following up with this patchset sooner as I was busy on other > tasks. Thanks for continuing with this. > 1) The "cpuset.cpus" is not empty and the list of CPUs are > exclusive, i.e. they are not shared by any of its siblings. > 2) The parent cgroup is a partition root. > 3) The "cpuset.cpus" is a subset of the union of parent's > "cpuset.cpus.effective" and offlined CPUs in parent's > "cpuset.cpus". > 4) There is no child cgroups with cpuset enabled. This avoids > cpu migrations of multiple cgroups simultaneously which can > be problematic. > > A partition, when enabled, can be in an invalid state. An example > is when its parent is also an invalid partition. You say: "it can only be enabled in a cgroup if all the following conditions are met.", "2) The parent cgroup is a partition root." and then the example: "A partition, when enabled, can be in an invalid state. An example is when its parent is also an invalid partition." But the first two statements imply you can't have enabled the partition in such a case. I think there is still mixup of partition validity conditions and transition conditions, yours would roughly divide into (not precisely, just to share my understanding): Validity conditions 1) The "cpuset.cpus" is not empty and the list of CPUs are exclusive, i.e. they are not shared by any of its siblings. 2) The parent cgroup is a partition root. Transition conditions: 3) The "cpuset.cpus" is a subset of the union of parent's "cpuset.cpus.effective" and offlined CPUs in parent's "cpuset.cpus". 4) There is no child cgroups with cpuset enabled. This avoids cpu migrations of multiple cgroups simultaneously which can be problematic. (I've put no. 3 into transition conditions because _after_ the transition parent's cpuset.cpus.effective are subtracted the new root's cpuset.cpus but I'd like to have something similar as a validity condition but I haven't come up with that yet.) I consider the following situation: r // all cpus 0-7 `- part1 cpus=0-3 root >partition ` subpart1 cpus=0-1 root >partition ` subpart2 cpus=2-3 root >partition `- other cpus=4-7 // member by default Both subpart1 and subpart2 are valid partition roots. Look at actions listed below (as alternatives, not a sequence): a) hotplug offlines cpu 3 - would part1 still be considered a valid root? - perhaps not - would subpart1 still be considered a valid root? - it could be, but its parent is invalid so no? - would subpart2 still be considered a valid root? - perhaps not b) administrative change writes 0-2 into part1 cpus - would part1 still be considered a valid root? - yes - would subpart1 still be considered a valid root? - yes - would subpart2 still be considered a valid root? - perhaps not c) administrative change writes 3-7 into `other` cpus - should this fail or invalidate a root partition part1? - perhaps fail since the same "owner" manages all siblings and should reduce part1 first The answers above are just my "natural" responses, the ideal may be different. The issue I want to illustrate is that if all the conditions are formed as transition conditions only, they can't be used to reason about hotplug or config changes (except for cpuset.cpus.partitions writes). What would help me with the understanding -- the invalid root partition is defined as 1) such a cgroup where no cpus are granted from the top (and thus has to fall back to ancestors) or 2) such a cgroup where cpus requested in cpuset.cpus can't be fulfilled (i.e. any missing invalidates)? Furthermore, another example (motivated by the patch 4/6) r // all cpus 0-7 `- part1 cpus=0-4 root >partition ` subpart1 cpus=0-1 root >partition ` subpart2 cpus=2-3 root >partition ` task `- other cpus=5-7 // member by default It's a valid and achievable state (even on v2 since cpuset is a threaded controller). a) cpu 4 is offlined - this should invalidate part1 (and propagate invalidation into subpart1 and subpart2). b) administrative write 0-3 into part1 cpus - should this invalidate part1 or be rejected? In conclusion, it'd be good to have validity conditions separate from transition conditions (since hotplug transition can't be rejected) and perhaps treat administrative changes from an ancestor equally as a hotplug. Thanks, Michal

3 years, 2 months

2
2
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror October 2021