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

kselftest/next kselftest-livepatch: 3 runs, 2 regressions (v6.1-rc1-15-ga1d6cd88c897)

by kernelci.org bot

kselftest/next kselftest-livepatch: 3 runs, 2 regressions (v6.1-rc1-15-ga1d6cd88c897) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions ----------------+-------+---------------+----------+------------------------------+------------ mt8173-elm-hana | arm64 | lab-collabora | clang-15 | defconfig+kse...4-chromebook | 1 mt8173-elm-hana | arm64 | lab-collabora | gcc-10 | defconfig+kse...4-chromebook | 1 Details: https://kernelci.org/test/job/kselftest/branch/next/kernel/v6.1-rc1-15-ga1d… Test: kselftest-livepatch Tree: kselftest Branch: next Describe: v6.1-rc1-15-ga1d6cd88c897 URL: https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git SHA: a1d6cd88c8973cfb08ee85722488b1d6d5d16327 Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions ----------------+-------+---------------+----------+------------------------------+------------ mt8173-elm-hana | arm64 | lab-collabora | clang-15 | defconfig+kse...4-chromebook | 1 Details: https://kernelci.org/test/plan/id/6373926376f474b0a7e7db7b Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+kselftest+arm64-chromebook Compiler: clang-15 (Debian clang version 15.0.4-++20221026063345+db68723804fd-1~exp1~20221026063423.87) Plain log: https://storage.kernelci.org//kselftest/next/v6.1-rc1-15-ga1d6cd88c897/arm6… HTML log: https://storage.kernelci.org//kselftest/next/v6.1-rc1-15-ga1d6cd88c897/arm6… Rootfs: http://storage.kernelci.org/images/rootfs/debian/bullseye-kselftest/2022102… * kselftest-livepatch.login: https://kernelci.org/test/case/id/6373926376f474b0a7e7db7c failing since 28 days (last pass: linux-kselftest-next-6.0-rc2-11-g144eeb2fc761, first fail: v6.1-rc1) platform | arch | lab | compiler | defconfig | regressions ----------------+-------+---------------+----------+------------------------------+------------ mt8173-elm-hana | arm64 | lab-collabora | gcc-10 | defconfig+kse...4-chromebook | 1 Details: https://kernelci.org/test/plan/id/637393f38ccd0836f5e7dbdd Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+kselftest+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//kselftest/next/v6.1-rc1-15-ga1d6cd88c897/arm6… HTML log: https://storage.kernelci.org//kselftest/next/v6.1-rc1-15-ga1d6cd88c897/arm6… Rootfs: http://storage.kernelci.org/images/rootfs/debian/bullseye-kselftest/2022102… * kselftest-livepatch.login: https://kernelci.org/test/case/id/637393f38ccd0836f5e7dbde failing since 28 days (last pass: linux-kselftest-next-6.0-rc2-11-g144eeb2fc761, first fail: v6.1-rc1)

2 years, 10 months

1
0
0 0

kselftest/next kselftest-cpufreq: 2 runs, 2 regressions (v6.1-rc1-15-ga1d6cd88c897)

by kernelci.org bot

kselftest/next kselftest-cpufreq: 2 runs, 2 regressions (v6.1-rc1-15-ga1d6cd88c897) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions ----------------+-------+---------------+----------+------------------------------+------------ mt8173-elm-hana | arm64 | lab-collabora | clang-15 | defconfig+kse...4-chromebook | 1 mt8173-elm-hana | arm64 | lab-collabora | gcc-10 | defconfig+kse...4-chromebook | 1 Details: https://kernelci.org/test/job/kselftest/branch/next/kernel/v6.1-rc1-15-ga1d… Test: kselftest-cpufreq Tree: kselftest Branch: next Describe: v6.1-rc1-15-ga1d6cd88c897 URL: https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git SHA: a1d6cd88c8973cfb08ee85722488b1d6d5d16327 Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions ----------------+-------+---------------+----------+------------------------------+------------ mt8173-elm-hana | arm64 | lab-collabora | clang-15 | defconfig+kse...4-chromebook | 1 Details: https://kernelci.org/test/plan/id/63739262604aabc640e7db81 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+kselftest+arm64-chromebook Compiler: clang-15 (Debian clang version 15.0.4-++20221026063345+db68723804fd-1~exp1~20221026063423.87) Plain log: https://storage.kernelci.org//kselftest/next/v6.1-rc1-15-ga1d6cd88c897/arm6… HTML log: https://storage.kernelci.org//kselftest/next/v6.1-rc1-15-ga1d6cd88c897/arm6… Rootfs: http://storage.kernelci.org/images/rootfs/debian/bullseye-kselftest/2022102… * kselftest-cpufreq.login: https://kernelci.org/test/case/id/63739262604aabc640e7db82 failing since 28 days (last pass: linux-kselftest-next-6.0-rc2-11-g144eeb2fc761, first fail: v6.1-rc1) platform | arch | lab | compiler | defconfig | regressions ----------------+-------+---------------+----------+------------------------------+------------ mt8173-elm-hana | arm64 | lab-collabora | gcc-10 | defconfig+kse...4-chromebook | 1 Details: https://kernelci.org/test/plan/id/6373935237b1359068e7db4e Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+kselftest+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//kselftest/next/v6.1-rc1-15-ga1d6cd88c897/arm6… HTML log: https://storage.kernelci.org//kselftest/next/v6.1-rc1-15-ga1d6cd88c897/arm6… Rootfs: http://storage.kernelci.org/images/rootfs/debian/bullseye-kselftest/2022102… * kselftest-cpufreq.login: https://kernelci.org/test/case/id/6373935237b1359068e7db4f failing since 28 days (last pass: linux-kselftest-next-6.0-rc2-11-g144eeb2fc761, first fail: v6.1-rc1)

2 years, 10 months

1
0
0 0

kselftest/next build: 8 builds: 0 failed, 8 passed, 3 errors (v6.1-rc1-15-ga1d6cd88c897)

by kernelci.org bot

kselftest/next build: 8 builds: 0 failed, 8 passed, 3 errors (v6.1-rc1-15-ga1d6cd88c897) Full Build Summary: https://kernelci.org/build/kselftest/branch/next/kernel/v6.1-rc1-15-ga1d6cd… Tree: kselftest Branch: next Git Describe: v6.1-rc1-15-ga1d6cd88c897 Git Commit: a1d6cd88c8973cfb08ee85722488b1d6d5d16327 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git Built: 4 unique architectures Errors Detected: arm64: defconfig+kselftest (clang-15): 1 error defconfig+kselftest+arm64-chromebook (clang-15): 1 error arm: i386: x86_64: x86_64_defconfig+kselftest (clang-15): 1 error Errors summary: 3 error: write on a pipe with no reader ================================================================================ Detailed per-defconfig build reports: -------------------------------------------------------------------------------- defconfig+kselftest (arm64, clang-15) — PASS, 1 error, 0 warnings, 0 section mismatches Errors: error: write on a pipe with no reader -------------------------------------------------------------------------------- defconfig+kselftest (arm64, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- defconfig+kselftest+arm64-chromebook (arm64, clang-15) — PASS, 1 error, 0 warnings, 0 section mismatches Errors: error: write on a pipe with no reader -------------------------------------------------------------------------------- defconfig+kselftest+arm64-chromebook (arm64, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- i386_defconfig+kselftest (i386, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- multi_v7_defconfig+kselftest (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- x86_64_defconfig+kselftest (x86_64, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- x86_64_defconfig+kselftest (x86_64, clang-15) — PASS, 1 error, 0 warnings, 0 section mismatches Errors: error: write on a pipe with no reader --- For more info write to <info(a)kernelci.org>

2 years, 10 months

1
0
0 0

Re: BPF, cross-compiling, and selftests

by Anders Roxell

On Tue, 15 Nov 2022 at 13:36, Björn Töpel <bjorn(a)kernel.org> wrote: > Hi, Adding the kselftest list > I ran into build issues when building selftests/net on Ubuntu/Debian, > which is related to that BPF program builds usually needs libc (and the > corresponding target host configuration/defines). > > When I try to build selftests/net, on my Debian host I get: I've ran into this issue too building with tuxmake [1] that uses debian containers. > > clang -O2 -target bpf -c bpf/nat6to4.c -I../../bpf -I../../../../lib -I../../../../../usr/include/ -o /home/bjorn/src/linux/linux/tools/testing/selftests/net/bpf/nat6to4.o > In file included from bpf/nat6to4.c:27: > In file included from /usr/include/linux/bpf.h:11: > /usr/include/linux/types.h:5:10: fatal error: 'asm/types.h' file not found > #include <asm/types.h> > ^~~~~~~~~~~~~ > 1 error generated. > > asm/types.h lives in /usr/include/"TRIPLE" on Debian, say > /usr/include/x86_64-linux-gnu. Target BPF does not (obviously) add the > x86-64 search path. These kind of problems have been worked around in, > e.g., commit 167381f3eac0 ("selftests/bpf: Makefile fix "missing" > headers on build with -idirafter"). > > However, just adding the host specific path is not enough. Typically, > when you start to include libc files, like "sys/socket.h" it's > expected that host specific defines are set. On my x86-64 host: > > $ clang -dM -E - < /dev/null|grep x86_ > #define __x86_64 1 > #define __x86_64__ 1 > > $ clang -target riscv64-linux-gnu -dM -E - < /dev/null|grep xlen > #define __riscv_xlen 64 > > otherwise you end up with errors like the one below. > > Missing __x86_64__: > #if !defined __x86_64__ > # include <gnu/stubs-32.h> > #endif > > clang -O2 -target bpf -c bpf/nat6to4.c -idirafter /usr/lib/llvm-16/lib/clang/16.0.0/include -idirafter /usr/local/include -idirafter /usr/include/x86_64-linux-gnu -idirafter /usr/include -Wno-compare-distinct-pointer-types -I../../bpf -I../../../../lib -I../../../../../usr/include/ -o /home/bjorn/src/linux/linux/tools/testing/selftests/net/bpf/nat6to4.o > In file included from bpf/nat6to4.c:28: > In file included from /usr/include/linux/if.h:28: > In file included from /usr/include/x86_64-linux-gnu/sys/socket.h:22: > In file included from /usr/include/features.h:510: > /usr/include/x86_64-linux-gnu/gnu/stubs.h:7:11: fatal error: 'gnu/stubs-32.h' file not found > # include <gnu/stubs-32.h> > ^~~~~~~~~~~~~~~~ > 1 error generated. > > Now, say that we'd like to cross-compile for a platform. Should I make > sure that all the target compiler's "default defines" are exported to > the BPF-program build step? I did a hack for RISC-V a while back in > commit 6016df8fe874 ("selftests/bpf: Fix broken riscv build"). Not > super robust, and not something I'd like to see for all supported > platforms. > > Any ideas? Maybe a convenience switch to Clang/target bpf? :-) I added the same thing selftests/bpf have in their Makefile [2] and that highlighted another issue which is that selftests/net/bpf depends on bpf_helpers.h which in turn depends on the generated file bpf_helper_defs.h... Cheers, Anders [1] https://tuxmake.org/ [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/too…

2 years, 10 months

1
0
0 0

[PATCH 1/2] KVM: selftests: Allow >1 guest mode in access_tracking_perf_test

by Oliver Upton

As the name implies, for_each_guest_mode() will run the test case for all supported guest addressing modes. On x86 that doesn't amount to anything, but arm64 can handle 4K, 16K, and 64K page sizes on supporting hardware. Blindly attempting to run access_tracking_perf_test on arm64 stalls on the second test case, as the 'done' global remains set between test iterations. Clear it after VM teardown in anticipation of a subsequent test case. Signed-off-by: Oliver Upton <oliver.upton(a)linux.dev> --- tools/testing/selftests/kvm/access_tracking_perf_test.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/tools/testing/selftests/kvm/access_tracking_perf_test.c b/tools/testing/selftests/kvm/access_tracking_perf_test.c index 76c583a07ea2..4da066479e0a 100644 --- a/tools/testing/selftests/kvm/access_tracking_perf_test.c +++ b/tools/testing/selftests/kvm/access_tracking_perf_test.c @@ -326,6 +326,9 @@ static void run_test(enum vm_guest_mode mode, void *arg) perf_test_join_vcpu_threads(nr_vcpus); perf_test_destroy_vm(vm); + + /* Clear done in anticipation of testing another guest mode */ + done = false; } static void help(char *name) -- 2.38.1.431.g37b22c650d-goog

2 years, 10 months

3
3
0 0

[PATCH] kselftest/cgroup: Fix gathering number of CPUs

by Breno Leitao

test_cpuset_prs.sh is failing with the following error: test_cpuset_prs.sh: line 29: [[: 8 57%: syntax error in expression (error token is "57%") This is happening because `lscpu | grep "^CPU(s)"` returns two lines in some systems (such as Debian unstable): # lscpu | grep "^CPU(s)" CPU(s): 8 CPU(s) scaling MHz: 55% This is a simple fix that discard the second line. Signed-off-by: Breno Leitao <leitao(a)debian.org> --- tools/testing/selftests/cgroup/test_cpuset_prs.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/cgroup/test_cpuset_prs.sh b/tools/testing/selftests/cgroup/test_cpuset_prs.sh index 526d2c42d870..564ca8c33035 100755 --- a/tools/testing/selftests/cgroup/test_cpuset_prs.sh +++ b/tools/testing/selftests/cgroup/test_cpuset_prs.sh @@ -25,7 +25,7 @@ WAIT_INOTIFY=$(cd $(dirname $0); pwd)/wait_inotify CGROUP2=$(mount -t cgroup2 | head -1 | awk -e '{print $3}') [[ -n "$CGROUP2" ]] || skip_test "Cgroup v2 mount point not found!" -CPUS=$(lscpu | grep "^CPU(s)" | sed -e "s/.*:[[:space:]]*//") +CPUS=$(lscpu | grep "^CPU(s):" | sed -e "s/.*:[[:space:]]*//") [[ $CPUS -lt 8 ]] && skip_test "Test needs at least 8 cpus available!" # Set verbose flag and delay factor -- 2.38.1

2 years, 10 months

3
2
0 0

[PATCH] kselftest/arm64: fix array_size.cocci warning

by wangkailong＠jari.cn

Fix following coccicheck warning: tools/testing/selftests/arm64/mte/check_mmap_options.c:64:24-25: WARNING: Use ARRAY_SIZE tools/testing/selftests/arm64/mte/check_mmap_options.c:66:20-21: WARNING: Use ARRAY_SIZE tools/testing/selftests/arm64/mte/check_mmap_options.c:135:25-26: WARNING: Use ARRAY_SIZE tools/testing/selftests/arm64/mte/check_mmap_options.c:96:25-26: WARNING: Use ARRAY_SIZE tools/testing/selftests/arm64/mte/check_mmap_options.c:190:24-25: WARNING: Use ARRAY_SIZE Signed-off-by: KaiLong Wang <wangkailong(a)jari.cn> --- tools/testing/selftests/arm64/mte/check_mmap_options.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/tools/testing/selftests/arm64/mte/check_mmap_options.c b/tools/testing/selftests/arm64/mte/check_mmap_options.c index a04b12c21ac9..17694caaff53 100644 --- a/tools/testing/selftests/arm64/mte/check_mmap_options.c +++ b/tools/testing/selftests/arm64/mte/check_mmap_options.c @@ -61,9 +61,8 @@ static int check_anonymous_memory_mapping(int mem_type, int mode, int mapping, i { char *ptr, *map_ptr; int run, result, map_size; - int item = sizeof(sizes)/sizeof(int); + int item = ARRAY_SIZE(sizes); - item = sizeof(sizes)/sizeof(int); mte_switch_mode(mode, MTE_ALLOW_NON_ZERO_TAG); for (run = 0; run < item; run++) { map_size = sizes[run] + OVERFLOW + UNDERFLOW; @@ -93,7 +92,7 @@ static int check_file_memory_mapping(int mem_type, int mode, int mapping, int ta { char *ptr, *map_ptr; int run, fd, map_size; - int total = sizeof(sizes)/sizeof(int); + int total = ARRAY_SIZE(sizes); int result = KSFT_PASS; mte_switch_mode(mode, MTE_ALLOW_NON_ZERO_TAG); @@ -132,7 +131,7 @@ static int check_clear_prot_mte_flag(int mem_type, int mode, int mapping) { char *ptr, *map_ptr; int run, prot_flag, result, fd, map_size; - int total = sizeof(sizes)/sizeof(int); + int total = ARRAY_SIZE(sizes); prot_flag = PROT_READ | PROT_WRITE; mte_switch_mode(mode, MTE_ALLOW_NON_ZERO_TAG); @@ -187,7 +186,7 @@ static int check_clear_prot_mte_flag(int mem_type, int mode, int mapping) int main(int argc, char *argv[]) { int err; - int item = sizeof(sizes)/sizeof(int); + int item = ARRAY_SIZE(sizes); err = mte_default_setup(); if (err) -- 2.25.1

2 years, 10 months

2
1
0 0

[PATCH] selftests/ftrace: event_triggers: wait longer for test_event_enable

by Yipeng Zou

In some platform, the schedule event may came slowly, delay 100ms can't cover it. I was notice that on my board which running in low cpu_freq,and this selftests allways gose fail. So maybe we can check more times here to wait longer. Fixes: 43bb45da82f9 ("selftests: ftrace: Add a selftest to test event enable/disable func trigger") Signed-off-by: Yipeng Zou <zouyipeng(a)huawei.com> --- .../ftrace/test.d/ftrace/func_event_triggers.tc | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/tools/testing/selftests/ftrace/test.d/ftrace/func_event_triggers.tc b/tools/testing/selftests/ftrace/test.d/ftrace/func_event_triggers.tc index 8d26d5505808..3eea2abf68f9 100644 --- a/tools/testing/selftests/ftrace/test.d/ftrace/func_event_triggers.tc +++ b/tools/testing/selftests/ftrace/test.d/ftrace/func_event_triggers.tc @@ -38,11 +38,18 @@ cnt_trace() { test_event_enabled() { val=$1 + check_times=10 # wait for 10 * SLEEP_TIME at most - e=`cat $EVENT_ENABLE` - if [ "$e" != $val ]; then - fail "Expected $val but found $e" - fi + while [ $check_times -ne 0 ]; do + e=`cat $EVENT_ENABLE` + if [ "$e" == $val ]; then + return 0 + fi + sleep $SLEEP_TIME + check_times=$((check_times - 1)) + done + + fail "Expected $val but found $e" } run_enable_disable() { -- 2.17.1

2 years, 10 months

4
3
0 0

KUnit issues - Was: [igt-dev] [PATCH RFC v2 8/8] drm/i915: check if current->mm is not NULL

by Mauro Carvalho Chehab

Hi, I'm facing a couple of issues when testing KUnit with the i915 driver. The DRM subsystem and the i915 driver has, for a long time, his own way to do unit tests, which seems to be added before KUnit. I'm now checking if it is worth start using KUnit at i915. So, I wrote a RFC with some patches adding support for the tests we have to be reported using Kernel TAP and KUnit. There are basically 3 groups of tests there: - mock tests - check i915 hardware-independent logic; - live tests - run some hardware-specific tests; - perf tests - check perf support - also hardware-dependent. As they depend on i915 driver, they run only on x86, with PCI stack enabled, but the mock tests run nicely via qemu. The live and perf tests require a real hardware. As we run them together with our CI, which, among other things, test module unload/reload and test loading i915 driver with different modprobe parameters, the KUnit tests should be able to run as a module. While testing KUnit, I noticed a couple of issues: 1. kunit.py parser is currently broken when used with modules the parser expects "TAP version xx" output, but this won't happen when loading the kunit test driver. Are there any plans or patches fixing this issue? 2. current->mm is not initialized Some tests do mmap(). They need the mm user context to be initialized, but this is not happening right now. Are there a way to properly initialize it for KUnit? 3. there's no test filters for modules In order to be able to do proper CI automation, it is needed to be able to control what tests will run or not. That's specially interesting at development time where some tests may not apply or not run properly on new hardware. Are there any plans to add support for it at kunit_test_suites() when the driver is built as module? Ideally, the best would be to export a per-module filter_glob parameter on such cases. 4. there are actually 3 levels of tests on i915: - Level 1: mock, live, perf - Level 2: test group (mmap, fences, ...) - Level 3: unit tests Currently, KUnit seems to have just two levels (test suite and tests). Are there a way to add test groups there? Regards, Mauro Forwarded message: Date: Thu, 3 Nov 2022 14:51:38 +0000 From: Mauro Carvalho Chehab <mchehab(a)kernel.org> To: Cc: Thomas Hellström <thomas.hellstrom(a)linux.intel.com>, linux-kselftest(a)vger.kernel.org, Michał Winiarski <michal.winiarski(a)intel.com>, dri-devel(a)lists.freedesktop.org, intel-gfx(a)lists.freedesktop.org, Daniel Latypov <dlatypov(a)google.com>, linux-kernel(a)vger.kernel.org, igt-dev(a)lists.freedesktop.org, Matthew Auld <matthew.auld(a)intel.com>, Daniel Vetter <daniel(a)ffwll.ch>, Rodrigo Vivi <rodrigo.vivi(a)intel.com>, skhan(a)linuxfoundation.org, Isabella Basso <isabbasso(a)riseup.net>, David Airlie <airlied(a)gmail.com>, Christian König <christian.koenig(a)amd.com> Subject: [igt-dev] [PATCH RFC v2 8/8] drm/i915: check if current->mm is not NULL The mmap tests require mm in order to work. Failing to do that will cause a crash: [ 316.820722] BUG: kernel NULL pointer dereference, address: 00000000000000e8 [ 316.822517] #PF: supervisor write access in kernel mode [ 316.823430] #PF: error_code(0x0002) - not-present page [ 316.824390] PGD 0 P4D 0 [ 316.825357] Oops: 0002 [#1] PREEMPT SMP NOPTI [ 316.826350] CPU: 0 PID: 1517 Comm: kunit_try_catch Tainted: G U N 6.1.0-rc2-drm-266703e6f163+ #14 [ 316.827503] Hardware name: Intel Corporation Tiger Lake Client Platform/TigerLake Y LPDDR4x T4 Crb, BIOS TGLSFWI1.R00.3243.A01.2006102133 06/10/2020 [ 316.828633] RIP: 0010:down_write_killable+0x50/0x110 [ 316.829756] Code: 24 10 45 31 c9 31 c9 41 b8 01 00 00 00 31 d2 31 f6 48 89 ef e8 e1 74 4a ff bf 01 00 00 00 e8 87 d6 46 ff 31 c0 ba 01 00 00 00 <f0> 48 0f b1 13 0f 94 c0 5a 84 c0 74 62 8b 05 49 12 e4 00 85 c0 74 [ 316.830896] RSP: 0018:ffffc90001eabc58 EFLAGS: 00010246 [ 316.832008] RAX: 0000000000000000 RBX: 00000000000000e8 RCX: 0000000000000000 [ 316.833141] RDX: 0000000000000001 RSI: ffffffff81c94fc9 RDI: ffffffff81c94fc9 [ 316.834195] RBP: 0000000000000158 R08: 0000000000000001 R09: 0000000000000000 [ 316.835231] R10: 0000000000000000 R11: ffff8883a13350b8 R12: 0000000000000002 [ 316.836259] R13: 0000000000000001 R14: 0000000000100000 R15: 00000000000000e8 [ 316.837237] FS: 0000000000000000(0000) GS:ffff8883a3800000(0000) knlGS:0000000000000000 [ 316.838214] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 316.839190] CR2: 00000000000000e8 CR3: 0000000002812003 CR4: 0000000000770ef0 [ 316.840147] PKRU: 55555554 [ 316.841099] Call Trace: [ 316.842047] <TASK> [ 316.842990] ? vm_mmap_pgoff+0x78/0x150 [ 316.843936] vm_mmap_pgoff+0x78/0x150 [ 316.844884] igt_mmap_offset+0x178/0x1b9 [i915] [ 316.846119] __igt_mmap+0xfe/0x680 [i915] Unfortunately, when KUnit module runs, it doesn't create an user context, causing mmap tests to fail. Signed-off-by: Mauro Carvalho Chehab <mchehab(a)kernel.org> --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH RFC v2 0/8] at: https://lore.kernel.org/all/cover.1667486144.git.mchehab@kernel.org/ drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c index add5ae56cd89..2c5f93e946b5 100644 --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c @@ -1845,6 +1845,11 @@ int i915_gem_mman_live_selftests(struct drm_i915_private *i915) SUBTEST(igt_mmap_gpu), }; + if (!current->mm) { + pr_err("Test called without an user context!\n"); + return -EINVAL; + } + return i915_live_subtests(tests, i915); } EXPORT_SYMBOL_NS_GPL(i915_gem_mman_live_selftests, I915_SELFTEST); -- 2.38.1

2 years, 10 months

4
9
0 0

[PATCH] selftests/damon: Fix unnecessary compilation warnings

by Rong Tao

From: Rong Tao <rongtao(a)cestc.cn> When testing overflow and overread, there is no need to keep unnecessary compilation warnings, we should simply ignore them. How to reproduce the problem: $ make -C tools/testing/selftests/ gcc huge_count_read_write.c -o /home/sd/Git/linux/tools/testing/selftests/damon/huge_count_read_write huge_count_read_write.c: In function ‘write_read_with_huge_count’: huge_count_read_write.c:23:9: warning: ‘write’ reading 4294967295 bytes from a region of size 1 [-Wstringop-overread] 23 | write(filedesc, "", 0xfffffffful); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from huge_count_read_write.c:8: /usr/include/unistd.h:378:16: note: in a call to function ‘write’ declared with attribute ‘access (read_only, 2, 3)’ 378 | extern ssize_t write (int __fd, const void *__buf, size_t __n) __wur | ^~~~~ huge_count_read_write.c:25:15: warning: ‘read’ writing 4294967295 bytes into a region of size 25 overflows the destination [-Wstringop-overflow=] 25 | ret = read(filedesc, buf, 0xfffffffful); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ huge_count_read_write.c:14:14: note: destination object ‘buf’ of size 25 14 | char buf[25]; | ^~~ In file included from huge_count_read_write.c:8: /usr/include/unistd.h:371:16: note: in a call to function ‘read’ declared with attribute ‘access (write_only, 2, 3)’ 371 | extern ssize_t read (int __fd, void *__buf, size_t __nbytes) __wur | ^~~~ Signed-off-by: Rong Tao <rongtao(a)cestc.cn> --- tools/testing/selftests/damon/huge_count_read_write.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/tools/testing/selftests/damon/huge_count_read_write.c b/tools/testing/selftests/damon/huge_count_read_write.c index ad7a6b4cf338..8fbe276870e7 100644 --- a/tools/testing/selftests/damon/huge_count_read_write.c +++ b/tools/testing/selftests/damon/huge_count_read_write.c @@ -8,6 +8,11 @@ #include <unistd.h> #include <stdio.h> +#pragma GCC diagnostic push +/* Ignore read(2) overflow and write(2) overread compile warnings */ +#pragma GCC diagnostic ignored "-Wstringop-overread" +#pragma GCC diagnostic ignored "-Wstringop-overflow" + void write_read_with_huge_count(char *file) { int filedesc = open(file, O_RDWR); @@ -27,6 +32,8 @@ void write_read_with_huge_count(char *file) close(filedesc); } +#pragma GCC diagnostic pop + int main(int argc, char *argv[]) { if (argc != 2) { -- 2.31.1

2 years, 10 months

2
7
0 0

[PATCH 2/2] KVM: selftests: Build access_tracking_perf_test for arm64

by Oliver Upton

Does exactly what it says on the tin. Signed-off-by: Oliver Upton <oliver.upton(a)linux.dev> --- tools/testing/selftests/kvm/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/testing/selftests/kvm/Makefile b/tools/testing/selftests/kvm/Makefile index 0172eb6cb6ee..4c0ff91a8964 100644 --- a/tools/testing/selftests/kvm/Makefile +++ b/tools/testing/selftests/kvm/Makefile @@ -156,6 +156,7 @@ TEST_GEN_PROGS_aarch64 += aarch64/psci_test TEST_GEN_PROGS_aarch64 += aarch64/vcpu_width_config TEST_GEN_PROGS_aarch64 += aarch64/vgic_init TEST_GEN_PROGS_aarch64 += aarch64/vgic_irq +TEST_GEN_PROGS_aarch64 += access_tracking_perf_test TEST_GEN_PROGS_aarch64 += demand_paging_test TEST_GEN_PROGS_aarch64 += dirty_log_test TEST_GEN_PROGS_aarch64 += dirty_log_perf_test -- 2.38.1.431.g37b22c650d-goog

2 years, 10 months

2
1
0 0

[PATCH bpf v2] selftests/bpf: Fix xdp_synproxy compilation failure in 32-bit arch

by Yang Jihong

xdp_synproxy fails to be compiled in the 32-bit arch, log is as follows: xdp_synproxy.c: In function 'parse_options': xdp_synproxy.c:175:36: error: left shift count >= width of type [-Werror=shift-count-overflow] 175 | *tcpipopts = (mss6 << 32) | (ttl << 24) | (wscale << 16) | mss4; | ^~ xdp_synproxy.c: In function 'syncookie_open_bpf_maps': xdp_synproxy.c:289:28: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] 289 | .map_ids = (__u64)map_ids, | ^ Fix it. Fixes: fb5cd0ce70d4 ("selftests/bpf: Add selftests for raw syncookie helpers") Signed-off-by: Yang Jihong <yangjihong1(a)huawei.com> --- tools/testing/selftests/bpf/xdp_synproxy.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/bpf/xdp_synproxy.c b/tools/testing/selftests/bpf/xdp_synproxy.c index ff35320d2be9..410a1385a01d 100644 --- a/tools/testing/selftests/bpf/xdp_synproxy.c +++ b/tools/testing/selftests/bpf/xdp_synproxy.c @@ -104,7 +104,8 @@ static void parse_options(int argc, char *argv[], unsigned int *ifindex, __u32 * { "tc", no_argument, NULL, 'c' }, { NULL, 0, NULL, 0 }, }; - unsigned long mss4, mss6, wscale, ttl; + unsigned long mss4, wscale, ttl; + unsigned long long mss6; unsigned int tcpipopts_mask = 0; if (argc < 2) @@ -286,7 +287,7 @@ static int syncookie_open_bpf_maps(__u32 prog_id, int *values_map_fd, int *ports prog_info = (struct bpf_prog_info) { .nr_map_ids = 8, - .map_ids = (__u64)map_ids, + .map_ids = (__u64)(unsigned long)map_ids, }; info_len = sizeof(prog_info); -- 2.30.GIT

2 years, 10 months

3
2
0 0

[PATCH bpf v2 0/2] Fix offset when fault occurs in strncpy_from_kernel_nofault()

by Alban Crequy

Hi, This is v2 of the fix & selftest previously sent at: https://lore.kernel.org/linux-mm/20221108195211.214025-1-flaniel@linux.micr… Changes v1 to v2: - add 'cc:stable', 'Fixes:' and review/ack tags - update commitmsg and fix my email - rebase on bpf tree and tag for bpf tree Thanks! Alban Crequy (2): maccess: fix writing offset in case of fault in strncpy_from_kernel_nofault() selftests: bpf: add a test when bpf_probe_read_kernel_str() returns EFAULT mm/maccess.c | 2 +- tools/testing/selftests/bpf/prog_tests/varlen.c | 7 +++++++ tools/testing/selftests/bpf/progs/test_varlen.c | 5 +++++ 3 files changed, 13 insertions(+), 1 deletion(-) -- 2.36.1

2 years, 10 months

2
3
0 0

[PATCH 0/7] KUnit documentation rewording

by Bagas Sanjaya

The proses written in KUnit documentation are IMO incomprehensible (my brain has to process what the meaning of words used) and different from wordings that I normally read from technical writings. Thus, rewrite these using clearer words. Anyway, it's great to see native English speakers help reviewing this series. The first two patches are v3 of rewriting "Writing Your First Test" section of "Getting Started" patch [1], which was submitted about a month ago. The rest are actual documentation rewriting. Note that this series only rewrites intro, test writing and running docs. [1]: https://lore.kernel.org/lkml/20220929132549.56452-1-bagasdotme@gmail.com/ Bagas Sanjaya (7): Documentation: kunit: rewrite "Writing Your First Test" section Documentation: kunit: align instruction code blocks Documentation: kunit: rewrite the rest of "Getting Started" documentation Documentation: kunit: move introduction to its own document Documentation: kunit: rewrite "Running tests with kunit_tool" Documentation: kunit: rewrite "Run Tests without kunit_tool" Documentation: kunit: rewrite "Writing tests" Documentation/admin-guide/README.rst | 2 + Documentation/dev-tools/kunit/index.rst | 93 +---- Documentation/dev-tools/kunit/intro.rst | 61 ++++ Documentation/dev-tools/kunit/run_manual.rst | 68 ++-- Documentation/dev-tools/kunit/run_wrapper.rst | 302 ++++++---------- Documentation/dev-tools/kunit/start.rst | 264 +++++++------- Documentation/dev-tools/kunit/usage.rst | 322 ++++++++++-------- 7 files changed, 483 insertions(+), 629 deletions(-) create mode 100644 Documentation/dev-tools/kunit/intro.rst base-commit: de3ee3f63400a23954e7c1ad1cb8c20f29ab6fe3 -- An old man doll... just what I always wanted! - Clara

2 years, 10 months

2
10
0 0

Re: [PATCH v6 2/3] fs/proc/task_mmu: Implement IOCTL to get and/or the clear info about PTEs

by Muhammad Usama Anjum

I've fixed these build failure for the next patch iteration. Please comment and review on the patch. I'll wait for a few days before sending next version. On 11/11/22 10:13 PM, kernel test robot wrote: > Hi Muhammad, > > Thank you for the patch! Yet something to improve: > > [auto build test ERROR on next-20221109] > [also build test ERROR on v6.1-rc4] > [cannot apply to shuah-kselftest/next shuah-kselftest/fixes linus/master v6.1-rc4 v6.1-rc3 v6.1-rc2] > [If your patch is applied to the wrong git tree, kindly drop us a note. > And when submitting patch, we suggest to use '--base' as documented in > https://git-scm.com/docs/git-format-patch#_base_tree_information] > > url: https://github.com/intel-lab-lkp/linux/commits/Muhammad-Usama-Anjum/Impleme… > patch link: https://lore.kernel.org/r/20221109102303.851281-3-usama.anjum%40collabora.c… > patch subject: [PATCH v6 2/3] fs/proc/task_mmu: Implement IOCTL to get and/or the clear info about PTEs > config: arm-buildonly-randconfig-r006-20221111 > compiler: clang version 16.0.0 (https://github.com/llvm/llvm-project 463da45892e2d2a262277b91b96f5f8c05dc25d0) > reproduce (this is a W=1 build): > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross > chmod +x ~/bin/make.cross > # install arm cross compiling tool for clang build > # apt-get install binutils-arm-linux-gnueabi > # https://github.com/intel-lab-lkp/linux/commit/b329378abd03a741ff7250ec1b602… > git remote add linux-review https://github.com/intel-lab-lkp/linux > git fetch --no-tags linux-review Muhammad-Usama-Anjum/Implement-IOCTL-to-get-and-or-the-clear-info-about-PTEs/20221109-182618 > git checkout b329378abd03a741ff7250ec1b60292c893476da > # save the config file > mkdir build_dir && cp config build_dir/.config > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=arm SHELL=/bin/bash fs/ > > If you fix the issue, kindly add following tag where applicable > | Reported-by: kernel test robot <lkp(a)intel.com> > > All errors (new ones prefixed by >>): > >>> fs/proc/task_mmu.c:1882:41: error: use of undeclared identifier 'HPAGE_SIZE' > if ((IS_CLEAR_OP(p) && (end - addr < HPAGE_SIZE))) { > ^ > 1 error generated. > > > vim +/HPAGE_SIZE +1882 fs/proc/task_mmu.c > > 1856 > 1857 static int pagemap_scan_pmd_entry(pmd_t *pmd, unsigned long addr, > 1858 unsigned long end, struct mm_walk *walk) > 1859 { > 1860 struct pagemap_scan_private *p = walk->private; > 1861 struct vm_area_struct *vma = walk->vma; > 1862 unsigned int len; > 1863 spinlock_t *ptl; > 1864 int ret = 0; > 1865 pte_t *pte; > 1866 bool dirty_vma = (p->flags & PAGEMAP_NO_REUSED_REGIONS) ? > 1867 (false) : (vma->vm_flags & VM_SOFTDIRTY); > 1868 > 1869 if ((walk->vma->vm_end < addr) || (p->max_pages && p->found_pages == p->max_pages)) > 1870 return 0; > 1871 > 1872 end = min(end, walk->vma->vm_end); > 1873 > 1874 ptl = pmd_trans_huge_lock(pmd, vma); > 1875 if (ptl) { > 1876 if (dirty_vma || check_soft_dirty_pmd(vma, addr, pmd, false)) { > 1877 /* > 1878 * Break huge page into small pages if operation needs to be performed is > 1879 * on a portion of the huge page or the return buffer cannot store complete > 1880 * data. > 1881 */ >> 1882 if ((IS_CLEAR_OP(p) && (end - addr < HPAGE_SIZE))) { > 1883 spin_unlock(ptl); > 1884 split_huge_pmd(vma, pmd, addr); > 1885 goto process_smaller_pages; > 1886 } > 1887 > 1888 if (IS_GET_OP(p)) { > 1889 len = (end - addr)/PAGE_SIZE; > 1890 if (p->max_pages && p->found_pages + len > p->max_pages) > 1891 len = p->max_pages - p->found_pages; > 1892 > 1893 ret = add_to_out(dirty_vma || > 1894 check_soft_dirty_pmd(vma, addr, pmd, false), > 1895 vma->vm_file, pmd_present(*pmd), is_swap_pmd(*pmd), > 1896 p, addr, len); > 1897 } > 1898 if (!ret && IS_CLEAR_OP(p)) > 1899 check_soft_dirty_pmd(vma, addr, pmd, true); > 1900 } > 1901 spin_unlock(ptl); > 1902 return 0; > 1903 } > 1904 > 1905 process_smaller_pages: > 1906 if (pmd_trans_unstable(pmd)) > 1907 return 0; > 1908 > 1909 pte = pte_offset_map_lock(vma->vm_mm, pmd, addr, &ptl); > 1910 for (; addr < end && !ret && (!p->max_pages || (p->found_pages < p->max_pages)) > 1911 ; pte++, addr += PAGE_SIZE) { > 1912 if (IS_GET_OP(p)) > 1913 ret = add_to_out(dirty_vma || check_soft_dirty(vma, addr, pte, false), > 1914 vma->vm_file, pte_present(*pte), > 1915 is_swap_pte(*pte), p, addr, 1); > 1916 if (!ret && IS_CLEAR_OP(p)) > 1917 check_soft_dirty(vma, addr, pte, true); > 1918 } > 1919 pte_unmap_unlock(pte - 1, ptl); > 1920 cond_resched(); > 1921 > 1922 return 0; > 1923 } > 1924 > -- BR, Muhammad Usama Anjum

2 years, 10 months

1
0
0 0

[RESEND PATCH v6] x86/fpu: Trying to fix writing PKRU through ptrace

by Kyle Huey

Hello Linus, I've been trying since July to get this regression that was introduced in 5.14 fixed. This is my third time submitting this version of the patch in the last two months. Both prior submissions have not received any comments from (nor have they been applied by) the x86 maintainers. I don't really know what else to do at this point beyond "complain to the management" as it were. I appreciate anything you can do to unjam things here. - Kyle

2 years, 10 months

4
10
0 0

[PATCH v2 00/21] arm64/sme: Support SME 2 and SME 2.1

by Mark Brown

Arm have recently released versions 2 and 2.1 of the SME extension. Among the features introduced by SME 2 is some new architectural state, the ZT0 register. This series adds support for this and all the other features of the new SME versions. Since the architecture has been designed with the possibility of adding further ZTn registers in mind the interfaces added for ZT0 are done with this possibility in mind. As ZT0 is a simple fixed size register these interfaces are all fairly simple, the main complication is that ZT0 is only accessible when PSTATE.ZA is enabled. The memory allocation that we already do for PSTATE.ZA is extended to include space for ZT0. Due to textual collisions especially around the addition of hwcaps this is based on the concurrently sent series "arm64: Support for 2022 data processing instructions" but there is no meaningful interaction. v2: - Add missing initialisation of user->zt in signal context parsing. - Change the magic for ZT signal frames to 0x5a544e01 (ZTN0). Mark Brown (21): arm64/sme: Rename za_state to sme_state arm64: Document boot requirements for SME 2 arm64/sysreg: Update system registers for SME 2 and 2.1 arm64/sme: Document SME 2 and SME 2.1 ABI arm64/esr: Document ISS for ZT0 being disabled arm64/sme: Manually encode ZT0 load and store instructions arm64/sme: Enable host kernel to access ZT0 arm64/sme: Add basic enumeration for SME2 arm64/sme: Provide storage for ZT0 arm64/sme: Implement context switching for ZT0 arm64/sme: Implement signal handling for ZT arm64/sme: Implement ZT0 ptrace support arm64/sme: Add hwcaps for SME 2 and 2.1 features kselftest/arm64: Add a stress test program for ZT0 kselftest/arm64: Cover ZT in the FP stress test kselftest/arm64: Enumerate SME2 in the signal test utility code kselftest/arm64: Teach the generic signal context validation about ZT kselftest/arm64: Add test coverage for ZT register signal frames kselftest/arm64: Add SME2 coverage to syscall-abi kselftest/arm64: Add coverage of the ZT ptrace regset kselftest/arm64: Add coverage of SME 2 and 2.1 hwcaps Documentation/arm64/booting.rst | 10 + Documentation/arm64/elf_hwcaps.rst | 18 + Documentation/arm64/sme.rst | 52 ++- arch/arm64/include/asm/cpufeature.h | 6 + arch/arm64/include/asm/esr.h | 1 + arch/arm64/include/asm/fpsimd.h | 28 +- arch/arm64/include/asm/fpsimdmacros.h | 22 ++ arch/arm64/include/asm/hwcap.h | 6 + arch/arm64/include/asm/processor.h | 2 +- arch/arm64/include/uapi/asm/hwcap.h | 6 + arch/arm64/include/uapi/asm/sigcontext.h | 19 + arch/arm64/kernel/cpufeature.c | 27 ++ arch/arm64/kernel/cpuinfo.c | 6 + arch/arm64/kernel/entry-fpsimd.S | 30 +- arch/arm64/kernel/fpsimd.c | 53 ++- arch/arm64/kernel/hyp-stub.S | 6 + arch/arm64/kernel/idreg-override.c | 1 + arch/arm64/kernel/process.c | 21 +- arch/arm64/kernel/ptrace.c | 60 ++- arch/arm64/kernel/signal.c | 113 +++++- arch/arm64/tools/cpucaps | 1 + arch/arm64/tools/sysreg | 26 +- include/uapi/linux/elf.h | 1 + tools/testing/selftests/arm64/abi/hwcap.c | 115 ++++++ .../selftests/arm64/abi/syscall-abi-asm.S | 43 ++- .../testing/selftests/arm64/abi/syscall-abi.c | 40 +- tools/testing/selftests/arm64/fp/.gitignore | 2 + tools/testing/selftests/arm64/fp/Makefile | 5 + tools/testing/selftests/arm64/fp/fp-stress.c | 29 +- tools/testing/selftests/arm64/fp/sme-inst.h | 20 + tools/testing/selftests/arm64/fp/zt-ptrace.c | 365 ++++++++++++++++++ tools/testing/selftests/arm64/fp/zt-test.S | 324 ++++++++++++++++ .../testing/selftests/arm64/signal/.gitignore | 1 + .../selftests/arm64/signal/test_signals.h | 2 + .../arm64/signal/test_signals_utils.c | 3 + .../arm64/signal/testcases/testcases.c | 36 ++ .../arm64/signal/testcases/testcases.h | 1 + .../arm64/signal/testcases/zt_no_regs.c | 51 +++ .../arm64/signal/testcases/zt_regs.c | 85 ++++ 39 files changed, 1564 insertions(+), 73 deletions(-) create mode 100644 tools/testing/selftests/arm64/fp/zt-ptrace.c create mode 100644 tools/testing/selftests/arm64/fp/zt-test.S create mode 100644 tools/testing/selftests/arm64/signal/testcases/zt_no_regs.c create mode 100644 tools/testing/selftests/arm64/signal/testcases/zt_regs.c base-commit: ab0aff0601c29dc7b5cb2ecf42135dccbed6750a -- 2.30.2

2 years, 10 months

2
26
0 0

[PATCH bpf] selftests/bpf: Fix xdp_synproxy compilation failure in 32-bit arch

by Yang Jihong

xdp_synproxy fails to be compiled in the 32-bit arch, log is as follows: xdp_synproxy.c: In function 'parse_options': xdp_synproxy.c:175:36: error: left shift count >= width of type [-Werror=shift-count-overflow] 175 | *tcpipopts = (mss6 << 32) | (ttl << 24) | (wscale << 16) | mss4; | ^~ xdp_synproxy.c: In function 'syncookie_open_bpf_maps': xdp_synproxy.c:289:28: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] 289 | .map_ids = (__u64)map_ids, | ^ Fix it. Fixes: fb5cd0ce70d4 ("selftests/bpf: Add selftests for raw syncookie helpers") Signed-off-by: Yang Jihong <yangjihong1(a)huawei.com> --- tools/testing/selftests/bpf/xdp_synproxy.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/bpf/xdp_synproxy.c b/tools/testing/selftests/bpf/xdp_synproxy.c index ff35320d2be9..45fef01a87a8 100644 --- a/tools/testing/selftests/bpf/xdp_synproxy.c +++ b/tools/testing/selftests/bpf/xdp_synproxy.c @@ -172,7 +172,7 @@ static void parse_options(int argc, char *argv[], unsigned int *ifindex, __u32 * if (tcpipopts_mask == 0xf) { if (mss4 == 0 || mss6 == 0 || wscale == 0 || ttl == 0) usage(argv[0]); - *tcpipopts = (mss6 << 32) | (ttl << 24) | (wscale << 16) | mss4; + *tcpipopts = ((unsigned long long)mss6 << 32) | (ttl << 24) | (wscale << 16) | mss4; } else if (tcpipopts_mask != 0) { usage(argv[0]); } @@ -286,7 +286,7 @@ static int syncookie_open_bpf_maps(__u32 prog_id, int *values_map_fd, int *ports prog_info = (struct bpf_prog_info) { .nr_map_ids = 8, - .map_ids = (__u64)map_ids, + .map_ids = (__u64)(unsigned long)map_ids, }; info_len = sizeof(prog_info); -- 2.30.GIT

2 years, 10 months

2
2
0 0

[PATCH AUTOSEL 6.0 09/30] ksefltests: pidfd: Fix wait_states: Test terminated by timeout

by Sasha Levin

From: Li Zhijian <lizhijian(a)fujitsu.com> [ Upstream commit 88e1f16ba58665e9edfce437ea487da2fa759af9 ] 0Day/LKP observed that the kselftest blocks forever since one of the pidfd_wait doesn't terminate in 1 of 30 runs. After digging into the source, we found that it blocks at: ASSERT_EQ(sys_waitid(P_PIDFD, pidfd, &info, WCONTINUED, NULL), 0); wait_states has below testing flow: CHILD PARENT ---------------+-------------- 1 STOP itself 2 WAIT for CHILD STOPPED 3 SIGNAL CHILD to CONT 4 CONT 5 STOP itself 5' WAIT for CHILD CONT 6 WAIT for CHILD STOPPED The problem is that the kernel cannot ensure the order of 5 and 5', once 5 goes first, the test will fail. we can reproduce it by: $ while true; do make run_tests -C pidfd; done Introduce a blocking read in child process to make sure the parent can check its WCONTINUED. CC: Philip Li <philip.li(a)intel.com> Reported-by: kernel test robot <lkp(a)intel.com> Signed-off-by: Li Zhijian <lizhijian(a)fujitsu.com> Reviewed-by: Christian Brauner (Microsoft) <brauner(a)kernel.org> Signed-off-by: Shuah Khan <skhan(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- tools/testing/selftests/pidfd/pidfd_wait.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/tools/testing/selftests/pidfd/pidfd_wait.c b/tools/testing/selftests/pidfd/pidfd_wait.c index 070c1c876df1..c3e2a3041f55 100644 --- a/tools/testing/selftests/pidfd/pidfd_wait.c +++ b/tools/testing/selftests/pidfd/pidfd_wait.c @@ -95,20 +95,28 @@ TEST(wait_states) .flags = CLONE_PIDFD | CLONE_PARENT_SETTID, .exit_signal = SIGCHLD, }; + int pfd[2]; pid_t pid; siginfo_t info = { .si_signo = 0, }; + ASSERT_EQ(pipe(pfd), 0); pid = sys_clone3(&args); ASSERT_GE(pid, 0); if (pid == 0) { + char buf[2]; + + close(pfd[1]); kill(getpid(), SIGSTOP); + ASSERT_EQ(read(pfd[0], buf, 1), 1); + close(pfd[0]); kill(getpid(), SIGSTOP); exit(EXIT_SUCCESS); } + close(pfd[0]); ASSERT_EQ(sys_waitid(P_PIDFD, pidfd, &info, WSTOPPED, NULL), 0); ASSERT_EQ(info.si_signo, SIGCHLD); ASSERT_EQ(info.si_code, CLD_STOPPED); @@ -117,6 +125,8 @@ TEST(wait_states) ASSERT_EQ(sys_pidfd_send_signal(pidfd, SIGCONT, NULL, 0), 0); ASSERT_EQ(sys_waitid(P_PIDFD, pidfd, &info, WCONTINUED, NULL), 0); + ASSERT_EQ(write(pfd[1], "C", 1), 1); + close(pfd[1]); ASSERT_EQ(info.si_signo, SIGCHLD); ASSERT_EQ(info.si_code, CLD_CONTINUED); ASSERT_EQ(info.si_pid, parent_tid); -- 2.35.1

2 years, 10 months

1
0
0 0

[PATCH v2 1/2] selftests: proc: Fix proc-empty-vm build error on non x86_64

by Punit Agrawal

The proc-empty-vm test is implemented for x86_64 and fails to build for other architectures. Rather then emitting a compiler error it would be preferable to only build the test on supported architectures. Mark proc-empty-vm as a test for x86_64 and customise the Makefile to build it only when building for this target architecture. Fixes: 5bc73bb3451b ("proc: test how it holds up with mapping'less process") Signed-off-by: Punit Agrawal <punit.agrawal(a)bytedance.com> --- v1 -> v2 * Fixed missing compilation on x86_64 Previous version * https://lore.kernel.org/all/20221109110621.1791999-1-punit.agrawal@bytedanc… tools/testing/selftests/proc/Makefile | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/proc/Makefile b/tools/testing/selftests/proc/Makefile index cd95369254c0..743aaa0cdd52 100644 --- a/tools/testing/selftests/proc/Makefile +++ b/tools/testing/selftests/proc/Makefile @@ -1,14 +1,16 @@ # SPDX-License-Identifier: GPL-2.0-only + +# When ARCH not overridden for crosscompiling, lookup machine +ARCH ?= $(shell uname -m 2>/dev/null || echo not) + CFLAGS += -Wall -O2 -Wno-unused-function CFLAGS += -D_GNU_SOURCE LDFLAGS += -pthread -TEST_GEN_PROGS := TEST_GEN_PROGS += fd-001-lookup TEST_GEN_PROGS += fd-002-posix-eq TEST_GEN_PROGS += fd-003-kthread TEST_GEN_PROGS += proc-loadavg-001 -TEST_GEN_PROGS += proc-empty-vm TEST_GEN_PROGS += proc-pid-vm TEST_GEN_PROGS += proc-self-map-files-001 TEST_GEN_PROGS += proc-self-map-files-002 @@ -26,4 +28,8 @@ TEST_GEN_PROGS += thread-self TEST_GEN_PROGS += proc-multiple-procfs TEST_GEN_PROGS += proc-fsconfig-hidepid +TEST_GEN_PROGS_x86_64 += proc-empty-vm + +TEST_GEN_PROGS += $(TEST_GEN_PROGS_$(ARCH)) + include ../lib.mk -- 2.35.1

2 years, 10 months

3
7
0 0

[RFC PATCH 0/3] Use TAP in some more KVM selftests

by Thomas Huth

Many KVM selftests are completely silent. This has the disadvantage for the users that they do not know what's going on here. For example, some time ago, a tester asked me how to know whether a certain new sub-test has been added to one of the s390x test binaries or not (which he didn't compile on his own), which is hard to judge when there is no output. So I finally went ahead and implemented TAP output in the s390x-specific tests some months ago. Now I wonder whether that could be a good strategy for the x86 and generic tests, too? As a little RFC patch series, I've converted three more KVM selftests to use TAP output. If we decide that this is the right way to go, I can work on other tests later, too. Thomas Huth (3): KVM: selftests: Use TAP interface in the kvm_binary_stats_test KVM: selftests: x86: Use TAP interface in the sync_regs test KVM: selftests: x86: Use TAP interface in the tsc_msrs_test .../selftests/kvm/kvm_binary_stats_test.c | 11 +- .../selftests/kvm/x86_64/sync_regs_test.c | 113 ++++++++++++++---- .../selftests/kvm/x86_64/tsc_msrs_test.c | 16 ++- 3 files changed, 114 insertions(+), 26 deletions(-) -- 2.31.1

2 years, 10 months

4
9
0 0

[PATCH v3 0/5] Some improvements of resctrl selftest

by Shaopeng Tan

Hello, The aim of this patch series is to improve the resctrl selftest. Without these fixes, some unnecessary processing will be executed and test results will be confusing. There is no behavior change in test themselves. [patch 1] Make write_schemata() run to set up shemata with 100% allocation on first run in MBM test. [patch 2] The MBA test result message is always output as "ok", make output message to be "not ok" if MBA check result is failed. [patch 3] When a child process is created by fork(), the buffer of the parent process is also copied. Flush the buffer before executing fork(). [patch 4] Add a signal handler to cleanup properly before exiting the parent process, if there is an error occurs after creating a child process with fork() in the CAT test. [patch 5] Before exiting each test CMT/CAT/MBM/MBA, clear test result files function cat/cmt/mbm/mba_test_cleanup() are called twice. Delete once. This patch series is based on Linux v6.1-rc3 Difference from v2: Moved [PATCH v2 3/4] to the last and insert patch 4 before it. [patch 1] Fixed the typo miss in the changelog and initialized *p(resctrl_val_param) before use it. And since there was no MBM processing in write_schemata(), added it. [patch 4] A signal handler is introduced in this patch. With this patch, patch 5 clear duplicate code cat/cmt/mbm/mba_test_cleanup() without falling into the indicated trap. https://lore.kernel.org/lkml/bdb19cf6-dd4b-2042-7cda-7f6108e543aa@intel.com/ Pervious versions of this series: [v1] https://lore.kernel.org/lkml/20220914015147.3071025-1-tan.shaopeng@jp.fujit… [v2] https://lore.kernel.org/lkml/20221005013933.1486054-1-tan.shaopeng@jp.fujit… Shaopeng Tan (5): selftests/resctrl: Fix set up schemata with 100% allocation on first run in MBM test selftests/resctrl: Return MBA check result and make it to output message selftests/resctrl: Flush stdout file buffer before executing fork() selftests/resctrl: Cleanup properly when an error occurs in CAT test. selftests/resctrl: Remove duplicate codes that clear each test result file tools/testing/selftests/resctrl/cat_test.c | 29 +++++++++++++------ tools/testing/selftests/resctrl/mba_test.c | 8 ++--- tools/testing/selftests/resctrl/mbm_test.c | 13 +++++---- .../testing/selftests/resctrl/resctrl_tests.c | 4 --- tools/testing/selftests/resctrl/resctrl_val.c | 1 + tools/testing/selftests/resctrl/resctrlfs.c | 5 +++- 6 files changed, 36 insertions(+), 24 deletions(-) -- 2.27.0

2 years, 10 months

4
17
0 0

kselftest rtctests failed on arm64 Raspberry Pi 4 - rtctest.c:34:date_read:Expected -1 (-1) != self->fd (-1)

by Naresh Kamboju

kselftest rtctests failed on arm64 Raspberry Pi 4 Model B device and passed on other devices and qemu emulators. Please refer to the full logs and test comparison results links. Reported-by: Linux Kernel Functional Testing <lkft(a)linaro.org> Test run log: ------------- [ 248.627989] kselftest: Running tests in rtc TAP version 13 1..1 # selftests: rtc: rtctest [ 249.116824] audit: type=1701 audit(1651167970.071:12): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=2818 comm=\"rtctest\" exe=\"/opt/kselftests/default-in-kernel/rtc/rtctest\" sig=6 res=1 [ 249.133837] audit: type=1701 audit(1651167970.079:13): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=2819 comm=\"rtctest\" exe=\"/opt/kselftests/default-in-kernel/rtc/rtctest\" sig=6 res=1 [ 249.151179] audit: type=1701 audit(1651167970.083:14): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=2820 comm=\"rtctest\" exe=\"/opt/kselftests/default-in-kernel/rtc/rtctest\" sig=6 res=1 [ 249.168401] audit: type=1701 audit(1651167970.091:15): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=2821 comm=\"rtctest\" exe=\"/opt/kselftests/default-in-kernel/rtc/rtctest\" sig=6 res=1 [ 249.185406] audit: type=1701 audit(1651167970.095:16): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=2822 comm=\"rtctest\" exe=\"/opt/kselftests/default-in-kernel/rtc/rtctest\" sig=6 res=1 [ 249.202343] audit: type=1701 audit(1651167970.103:17): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=2823 comm=\"rtctest\" exe=\"/opt/kselftests/default-in-kernel/rtc/rtctest\" sig=6 res=1 #[ 249.219262] audit: type=1701 audit(1651167970.111:18): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=2824 comm=\"rtctest\" exe=\"/opt/kselftests/default-in-kernel/rtc/rtctest\" sig=6 res=1 [ 249.236233] audit: type=1701 audit(1651167970.115:19): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=2825 comm=\"rtctest\" exe=\"/opt/kselftests/default-in-kernel/rtc/rtctest\" sig=6 res=1 TAP version 13 # 1..8 # # Starting 8 tests from 2 test cases. # # RUN rtc.date_read ... # # rtctest.c:34:date_read:Expected -1 (-1) != self->fd (-1) # # date_read: Test terminated by assertion # # FAIL rtc.date_read # not ok 1 rtc.date_read # # RUN rtc.date_read_loop ... # # rtctest.c:34:date_read_loop:Expected -1 (-1) != self->fd (-1) # # date_read_loop: Test terminated by assertion # # FAIL rtc.date_read_loop # not ok 2 rtc.date_read_loop # # RUN rtc.uie_read ... # # rtctest.c:34:uie_read:Expected -1 (-1) != self->fd (-1) # # uie_read: Test terminated by assertion # # FAIL rtc.uie_read # not ok 3 rtc.uie_read # # RUN rtc.uie_select ... # # rtctest.c:34:uie_select:Expected -1 (-1) != self->fd (-1) # # uie_select: Test terminated by assertion # # FAIL rtc.uie_select # not ok 4 rtc.uie_select # # RUN rtc.alarm_alm_set ... # # rtctest.c:34:alarm_alm_set:Expected -1 (-1) != self->fd (-1) # # alarm_alm_set: Test terminated by assertion # # FAIL rtc.alarm_alm_set # not ok 5 rtc.alarm_alm_set # # RUN rtc.alarm_wkalm_set ... # # rtctest.c:34:alarm_wkalm_set:Expected -1 (-1) != self->fd (-1) # # alarm_wkalm_set: Test terminated by assertion # # FAIL rtc.alarm_wkalm_set # not ok 6 rtc.alarm_wkalm_set # # RUN rtc.alarm_alm_set_minute ... # # rtctest.c:34:alarm_alm_set_minute:Expected -1 (-1) != self->fd (-1) # # alarm_alm_set_minute: Test terminated by assertion # # FAIL rtc.alarm_alm_set_minute # not ok 7 rtc.alarm_alm_set_minute # # RUN rtc.alarm_wkalm_set_minute ... # # rtctest.c:34:alarm_wkalm_set_minute:Expected -1 (-1) != self->fd (-1) # # alarm_wkalm_set_minute: Test terminated by assertion # # FAIL rtc.alarm_wkalm_set_minute # not ok 8 rtc.alarm_wkalm_set_minute # # FAILED: 0 / 8 tests passed. # # Totals: pass:0 fail:8 xfail:0 xpass:0 skip:0 error:0 not ok 1 selftests: rtc: rtctest # exit=1 Test results details, https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20221107/te… Test results compare, https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20221107/te… Test detailed log, https://lkft.validation.linaro.org/scheduler/job/5812742#L1759 metadata: git_ref: master git_repo: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next git_sha: d8e87774068af213ab5b058b1b114dc397b577aa git_describe: next-20221107 kernel_version: 6.1.0-rc3 kernel-config: https://builds.tuxbuild.com/2HChVOSNxUpvfAfLTnaK7zyTdUi/config build-url: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next/-/pipelines/687092361 artifact-location: https://builds.tuxbuild.com/2HChVOSNxUpvfAfLTnaK7zyTdUi toolchain: gcc-11 -- Linaro QA https://qa-reports.linaro.org

2 years, 10 months

2
2
0 0

[PATCH RESEND 0/7] KUnit documentation rewording

by Bagas Sanjaya

Hi everyone, sorry for quickly resending this patch series due to duplicated patch [7/7] sent as result of amending the corresponding commit. The proses written in KUnit documentation are IMO incomprehensible (my brain has to process what the meaning of words used) and different from wordings that I normally read from technical writings. Thus, rewrite these using clearer words. Anyway, it's great to see native English speakers help reviewing this series. The first two patches are v3 of rewriting "Writing Your First Test" section of "Getting Started" patch [1], which was submitted about a month ago. The rest are actual documentation rewriting. Note that this series only rewrites intro, test writing and running docs. [1]: https://lore.kernel.org/lkml/20220929132549.56452-1-bagasdotme@gmail.com/ Bagas Sanjaya (7): Documentation: kunit: rewrite "Writing Your First Test" section Documentation: kunit: align instruction code blocks Documentation: kunit: rewrite the rest of "Getting Started" documentation Documentation: kunit: move introduction to its own document Documentation: kunit: rewrite "Running tests with kunit_tool" Documentation: kunit: rewrite "Run Tests without kunit_tool" Documentation: kunit: rewrite "Writing tests" Documentation/admin-guide/README.rst | 2 + Documentation/dev-tools/kunit/index.rst | 93 +---- Documentation/dev-tools/kunit/intro.rst | 61 ++++ Documentation/dev-tools/kunit/run_manual.rst | 68 ++-- Documentation/dev-tools/kunit/run_wrapper.rst | 302 ++++++---------- Documentation/dev-tools/kunit/start.rst | 264 +++++++------- Documentation/dev-tools/kunit/usage.rst | 322 ++++++++++-------- 7 files changed, 483 insertions(+), 629 deletions(-) create mode 100644 Documentation/dev-tools/kunit/intro.rst base-commit: de3ee3f63400a23954e7c1ad1cb8c20f29ab6fe3 -- An old man doll... just what I always wanted! - Clara

2 years, 10 months

1
8
0 0

[RFC PATCH 3/3] KVM: selftests: Test user hypercalls

by Oliver Upton

Signed-off-by: Oliver Upton <oliver.upton(a)linux.dev> --- tools/testing/selftests/kvm/.gitignore | 1 + tools/testing/selftests/kvm/Makefile | 1 + .../selftests/kvm/aarch64/user_hypercalls.c | 130 ++++++++++++++++++ 3 files changed, 132 insertions(+) create mode 100644 tools/testing/selftests/kvm/aarch64/user_hypercalls.c diff --git a/tools/testing/selftests/kvm/.gitignore b/tools/testing/selftests/kvm/.gitignore index 2f0d705db9db..4f45e987985f 100644 --- a/tools/testing/selftests/kvm/.gitignore +++ b/tools/testing/selftests/kvm/.gitignore @@ -5,6 +5,7 @@ /aarch64/get-reg-list /aarch64/hypercalls /aarch64/psci_test +/aarch64/user_hypercalls /aarch64/vcpu_width_config /aarch64/vgic_init /aarch64/vgic_irq diff --git a/tools/testing/selftests/kvm/Makefile b/tools/testing/selftests/kvm/Makefile index 0172eb6cb6ee..8ac1988ea669 100644 --- a/tools/testing/selftests/kvm/Makefile +++ b/tools/testing/selftests/kvm/Makefile @@ -153,6 +153,7 @@ TEST_GEN_PROGS_aarch64 += aarch64/debug-exceptions TEST_GEN_PROGS_aarch64 += aarch64/get-reg-list TEST_GEN_PROGS_aarch64 += aarch64/hypercalls TEST_GEN_PROGS_aarch64 += aarch64/psci_test +TEST_GEN_PROGS_aarch64 += aarch64/user_hypercalls TEST_GEN_PROGS_aarch64 += aarch64/vcpu_width_config TEST_GEN_PROGS_aarch64 += aarch64/vgic_init TEST_GEN_PROGS_aarch64 += aarch64/vgic_irq diff --git a/tools/testing/selftests/kvm/aarch64/user_hypercalls.c b/tools/testing/selftests/kvm/aarch64/user_hypercalls.c new file mode 100644 index 000000000000..94ac821c5474 --- /dev/null +++ b/tools/testing/selftests/kvm/aarch64/user_hypercalls.c @@ -0,0 +1,130 @@ +// SPDX-License-Identifier: GPL-2.0-only + +#include <linux/arm-smccc.h> + +#include "kvm_util.h" +#include "processor.h" +#include "test_util.h" + +struct test_case { + uint64_t cap; + uint32_t function; + uint64_t args[6]; +}; + +#define TEST_OWNER(name) \ +{ \ + .cap = BIT_ULL(KVM_ARM_USER_HYPERCALL_OWNER_ ## name), \ + .function = ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \ + ARM_SMCCC_SMC_32, \ + ARM_SMCCC_OWNER_ ## name, \ + 0), \ + .args = { \ + __LINE__, \ + __LINE__ + 1, \ + __LINE__ + 2, \ + __LINE__ + 3, \ + __LINE__ + 4, \ + __LINE__ + 5, \ + }, \ +}, \ +{ \ + .cap = BIT_ULL(KVM_ARM_USER_HYPERCALL_OWNER_ ## name), \ + .function = ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \ + ARM_SMCCC_SMC_64, \ + ARM_SMCCC_OWNER_ ## name, \ + 0), \ + .args = { \ + __LINE__, \ + __LINE__ + 1, \ + __LINE__ + 2, \ + __LINE__ + 3, \ + __LINE__ + 4, \ + __LINE__ + 5, \ + }, \ +} \ + +static struct test_case test_cases[] = { + TEST_OWNER(ARCH), + TEST_OWNER(CPU), + TEST_OWNER(SIP), + TEST_OWNER(OEM), + TEST_OWNER(STANDARD), + TEST_OWNER(STANDARD_HYP), + TEST_OWNER(VENDOR_HYP), + TEST_OWNER(TRUSTED_APP), + TEST_OWNER(TRUSTED_OS), +}; + +static void guest_main(const struct test_case *test) +{ + struct arm_smccc_res unused; + + smccc_hvc(test->function, test->args[0], test->args[1], test->args[2], + test->args[3], test->args[4], test->args[5], 0, &unused); + + GUEST_ASSERT(0); +} + +static void handle_hvc(const struct test_case *test, struct kvm_vcpu *vcpu) +{ + struct kvm_run *run = vcpu->run; + + TEST_ASSERT(run->hypercall.nr == test->function, + "unexpected function ID: %llx (expected %x)", + run->hypercall.nr, test->function); + + TEST_ASSERT(!memcmp(&run->hypercall.args, &test->args, sizeof(test->args)), + "unexpected hypercall arguments"); +} + +static void handle_ucall(struct kvm_vcpu *vcpu) +{ + struct ucall uc; + + switch (get_ucall(vcpu, &uc)) { + case UCALL_ABORT: + REPORT_GUEST_ASSERT(uc); + break; + default: + TEST_FAIL("unhandled ucall: %lu", uc.cmd); + } +} + +static void run_test(const struct test_case *test) +{ + struct kvm_vcpu *vcpu; + struct kvm_vm *vm; + + vm = vm_create_with_one_vcpu(&vcpu, guest_main); + vm_enable_cap(vm, KVM_CAP_ARM_USER_HYPERCALLS, test->cap); + ucall_init(vm, NULL); + + vcpu_args_set(vcpu, 1, test); + + vcpu_run(vcpu); + switch (vcpu->run->exit_reason) { + case KVM_EXIT_HYPERCALL: + handle_hvc(test, vcpu); + break; + case KVM_EXIT_MMIO: + handle_ucall(vcpu); + break; + default: + TEST_FAIL("unhandled exit reason: %u (%s)", vcpu->run->exit_reason, + exit_reason_str(vcpu->run->exit_reason)); + } + + ucall_uninit(vm); + kvm_vm_free(vm); +} + +int main(void) +{ + int i; + + TEST_REQUIRE(kvm_has_cap(KVM_CAP_ARM_USER_HYPERCALLS)); + + for (i = 0; i < ARRAY_SIZE(test_cases); i++) + run_test(&test_cases[i]); +} -- 2.38.1.431.g37b22c650d-goog

2 years, 10 months

1
0
0 0

Re: [PATCH v4 15/17] iommufd: Add a selftest

by Matthew Rosato

On 11/7/22 7:49 PM, Jason Gunthorpe wrote: > Cover the essential functionality of the iommufd with a directed > test. This aims to achieve reasonable functional coverage using the > in-kernel self test framework. > > It provides a mock kernel module for the iommu_domain that allows it to > run without any HW and the mocking provides a way to directly validate > that the PFNs loaded into the iommu_domain are correct. > > The mock also simulates the rare case of PAGE_SIZE > iommu page size as > the mock will operate at a 2K iommu page size. This allows exercising all > of the calculations to support this mismatch. > > This allows achieving high coverage of the corner cases in the iopt_pages. > > However, it is an unusually invasive config option to enable all of > this. The config option should not be enabled in a production kernel. > > Tested-by: Nicolin Chen <nicolinc(a)nvidia.com> > Signed-off-by: Jason Gunthorpe <jgg(a)nvidia.com> > Signed-off-by: Nicolin Chen <nicolinc(a)nvidia.com> > Signed-off-by: Yi Liu <yi.l.liu(a)intel.com> Ran the selftests on s390 in both LPAR (z16) and a QEMU kvm guest using 1M hugepages, all tests are passing. Tested-by: Matthew Rosato <mjrosato(a)linux.ibm.com> # s390

2 years, 10 months

1
0
0 0

[PATCH] selftests: proc: Fix proc-empty-vm build error on non x86_64

by Punit Agrawal

The proc-empty-vm test is implemented for x86_64 and fails to build for other architectures. Rather then emitting a compiler error it would be preferable to only build the test on supported architectures. Mark proc-empty-vm as a test for x86_64 and customise to the Makefile to build it only when building for this target architecture. Fixes: 5bc73bb3451b ("proc: test how it holds up with mapping'less process") Signed-off-by: Punit Agrawal <punit.agrawal(a)bytedance.com> --- tools/testing/selftests/proc/Makefile | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/proc/Makefile b/tools/testing/selftests/proc/Makefile index cd95369254c0..6b31439902af 100644 --- a/tools/testing/selftests/proc/Makefile +++ b/tools/testing/selftests/proc/Makefile @@ -1,14 +1,18 @@ # SPDX-License-Identifier: GPL-2.0-only + +# When ARCH not overridden for crosscompiling, lookup machine +ARCH ?= $(shell uname -m 2>/dev/null || echo not) + CFLAGS += -Wall -O2 -Wno-unused-function CFLAGS += -D_GNU_SOURCE LDFLAGS += -pthread -TEST_GEN_PROGS := +TEST_GEN_PROGS_x86_64 += proc-empty-vm + TEST_GEN_PROGS += fd-001-lookup TEST_GEN_PROGS += fd-002-posix-eq TEST_GEN_PROGS += fd-003-kthread TEST_GEN_PROGS += proc-loadavg-001 -TEST_GEN_PROGS += proc-empty-vm TEST_GEN_PROGS += proc-pid-vm TEST_GEN_PROGS += proc-self-map-files-001 TEST_GEN_PROGS += proc-self-map-files-002 -- 2.30.2

2 years, 10 months

2
3
0 0

[PATCH] selftests/bpf: Fix test_progs compilation failure in 32-bit arch

by Yang Jihong

test_progs fails to be compiled in the 32-bit arch, log is as follows: test_progs.c:1013:52: error: format '%ld' expects argument of type 'long int', but argument 3 has type 'size_t' {aka 'unsigned int'} [-Werror=format=] 1013 | sprintf(buf, "MSG_TEST_LOG (cnt: %ld, last: %d)", | ~~^ | | | long int | %d 1014 | strlen(msg->test_log.log_buf), | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | | size_t {aka unsigned int} Fix it. Fixes: 91b2c0afd00c ("selftests/bpf: Add parallelism to test_progs") Signed-off-by: Yang Jihong <yangjihong1(a)huawei.com> --- tools/testing/selftests/bpf/test_progs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/bpf/test_progs.c b/tools/testing/selftests/bpf/test_progs.c index 0e9a47f97890..3fef451d8831 100644 --- a/tools/testing/selftests/bpf/test_progs.c +++ b/tools/testing/selftests/bpf/test_progs.c @@ -1010,7 +1010,7 @@ static inline const char *str_msg(const struct msg *msg, char *buf) msg->subtest_done.have_log); break; case MSG_TEST_LOG: - sprintf(buf, "MSG_TEST_LOG (cnt: %ld, last: %d)", + sprintf(buf, "MSG_TEST_LOG (cnt: %zu, last: %d)", strlen(msg->test_log.log_buf), msg->test_log.is_last); break; -- 2.30.GIT

2 years, 10 months

3
2
0 0

[PATCH v1 0/6] arm64: Support for 2022 data processing instructions

by Mark Brown

The 2022 update to the Arm architecture includes a number of additions of generic data processing features, covering the base architecture, SVE and SME. Other than SME these are all simple features which introduce no architectural state so we simply need to expose hwcaps for them. This series covers these simple features. Since the SME updates do introduce new architectural state for which we must add new ABI they will be handled in a separate series. Mark Brown (6): arm64/hwcap: Add support for FEAT_CSSC kselftest/arm64: Add FEAT_CSSC to the hwcap selftest arm64/hwcap: Add support for FEAT_RPRFM kselftest/arm64: Add FEAT_RPRFM to the hwcap test arm64/hwcap: Add support for SVE 2.1 kselftest/arm64: Add SVE 2.1 to hwcap test Documentation/arm64/elf_hwcaps.rst | 9 +++++++ Documentation/arm64/sve.rst | 1 + arch/arm64/include/asm/hwcap.h | 3 +++ arch/arm64/include/uapi/asm/hwcap.h | 3 +++ arch/arm64/kernel/cpufeature.c | 5 ++++ arch/arm64/kernel/cpuinfo.c | 3 +++ arch/arm64/tools/sysreg | 12 ++++++++- tools/testing/selftests/arm64/abi/hwcap.c | 32 +++++++++++++++++++++++ 8 files changed, 67 insertions(+), 1 deletion(-) base-commit: 9abf2313adc1ca1b6180c508c25f22f9395cc780 -- 2.30.2

2 years, 10 months

3
13
0 0

[RFC PATCH v1 0/2] Fix offset when fault occurs in strncpy_from_kernel_nofault()

by Francis Laniel

Hi. First of all, I hope you are fine and the same for your relatives. This contribution fixes a bug where the byte before the destination address can be reset when a page fault occurs in strncpy_from_kernel_nofault() while copying the first byte from the source address. This bug leaded to kernel panic if a pointer containing the modified address is dereferenced as the pointer does not contain a correct addresss. To fix this bug, we simply reset the current destination byte in a case of a page fault. The proposed fix was tested and validated inside a VM: root@vm-amd64:~# ./share/linux/tools/testing/selftests/bpf/test_progs --name varlen ... #222 varlen:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED Without the patch, the test will fail: root@vm-amd64:~# ./share/linux/tools/testing/selftests/bpf/test_progs --name varlen ... #222 varlen:FAIL Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED If you see any way to improve this contribution, feel free to share. Alban Crequy (2): maccess: fix writing offset in case of fault in strncpy_from_kernel_nofault() selftests: bpf: add a test when bpf_probe_read_kernel_str() returns EFAULT mm/maccess.c | 2 +- tools/testing/selftests/bpf/prog_tests/varlen.c | 7 +++++++ tools/testing/selftests/bpf/progs/test_varlen.c | 5 +++++ 3 files changed, 13 insertions(+), 1 deletion(-) Best regards and thank you in advance. -- 2.25.1

2 years, 10 months

4
9
0 0

[PATCH v3 00/15] IOMMUFD Generic interface

by Jason Gunthorpe

[ At this point everything is done and I will start putting this work into a git tree and into linux-next with the intention of sending it during the next merge window. I intend to focus the next several weeks on more intensive QA to look at error flows and other things. Hopefully including syzkaller if I'm lucky ] iommufd is the user API to control the IOMMU subsystem as it relates to managing IO page tables that point at user space memory. It takes over from drivers/vfio/vfio_iommu_type1.c (aka the VFIO container) which is the VFIO specific interface for a similar idea. We see a broad need for extended features, some being highly IOMMU device specific: - Binding iommu_domain's to PASID/SSID - Userspace IO page tables, for ARM, x86 and S390 - Kernel bypassed invalidation of user page tables - Re-use of the KVM page table in the IOMMU - Dirty page tracking in the IOMMU - Runtime Increase/Decrease of IOPTE size - PRI support with faults resolved in userspace Many of these HW features exist to support VM use cases - for instance the combination of PASID, PRI and Userspace IO Page Tables allows an implementation of DMA Shared Virtual Addressing (vSVA) within a guest. Dirty tracking enables VM live migration with SRIOV devices and PASID support allow creating "scalable IOV" devices, among other things. As these features are fundamental to a VM platform they need to be uniformly exposed to all the driver families that do DMA into VMs, which is currently VFIO and VDPA. The pre-v1 series proposed re-using the VFIO type 1 data structure, however it was suggested that if we are doing this big update then we should also come with an improved data structure that solves the limitations that VFIO type1 has. Notably this addresses: - Multiple IOAS/'containers' and multiple domains inside a single FD - Single-pin operation no matter how many domains and containers use a page - A fine grained locking scheme supporting user managed concurrency for multi-threaded map/unmap - A pre-registration mechanism to optimize vIOMMU use cases by pre-pinning pages - Extended ioctl API that can manage these new objects and exposes domains directly to user space - domains are sharable between subsystems, eg VFIO and VDPA The bulk of this code is a new data structure design to track how the IOVAs are mapped to PFNs. iommufd intends to be general and consumable by any driver that wants to DMA to userspace. From a driver perspective it can largely be dropped in in-place of iommu_attach_device() and provides a uniform full feature set to all consumers. As this is a larger project this series is the first step. This series provides the iommfd "generic interface" which is designed to be suitable for applications like DPDK and VMM flows that are not optimized to specific HW scenarios. It is close to being a drop in replacement for the existing VFIO type 1 and supports existing qemu based VM flows. Several follow-on series are being prepared: - Patches integrating with qemu in native mode: https://github.com/yiliu1765/qemu/commits/qemu-iommufd-6.0-rc2 - A completed integration with VFIO now exists that covers "emulated" mdev use cases now, and can pass testing with qemu/etc in compatability mode: https://github.com/jgunthorpe/linux/commits/vfio_iommufd - A draft providing system iommu dirty tracking on top of iommufd, including iommu driver implementations: https://github.com/jpemartins/linux/commits/x86-iommufd This pairs with patches for providing a similar API to support VFIO-device tracking to give a complete vfio solution: https://lore.kernel.org/kvm/20220901093853.60194-1-yishaih@nvidia.com/ - Userspace page tables aka 'nested translation' for ARM and Intel iommu drivers: https://github.com/nicolinc/iommufd/commits/iommufd_nesting - "device centric" vfio series to expose the vfio_device FD directly as a normal cdev, and provide an extended API allowing dynamically changing the IOAS binding: https://github.com/yiliu1765/iommufd/commits/iommufd-v6.0-rc2-nesting-0901 - Drafts for PASID and PRI interfaces are included above as well Overall enough work is done now to show the merit of the new API design and at least draft solutions to many of the main problems. Several people have contributed directly to this work: Eric Auger, Joao Martins, Kevin Tian, Lu Baolu, Nicolin Chen, Yi L Liu. Many more have participated in the discussions that lead here, and provided ideas. Thanks to all! The v1/v2 iommufd series has been used to guide a large amount of preparatory work that has now been merged. The general theme is to organize things in a way that makes injecting iommufd natural: - VFIO live migration support with mlx5 and hisi_acc drivers. These series need a dirty tracking solution to be really usable. https://lore.kernel.org/kvm/20220224142024.147653-1-yishaih@nvidia.com/ https://lore.kernel.org/kvm/20220308184902.2242-1-shameerali.kolothum.thodi… - Significantly rework the VFIO gvt mdev and remove struct mdev_parent_ops https://lore.kernel.org/lkml/20220411141403.86980-1-hch@lst.de/ - Rework how PCIe no-snoop blocking works https://lore.kernel.org/kvm/0-v3-2cf356649677+a32-intel_no_snoop_jgg@nvidia… - Consolidate dma ownership into the iommu core code https://lore.kernel.org/linux-iommu/20220418005000.897664-1-baolu.lu@linux.… - Make all vfio driver interfaces use struct vfio_device consistently https://lore.kernel.org/kvm/0-v4-8045e76bf00b+13d-vfio_mdev_no_group_jgg@nv… - Remove the vfio_group from the kvm/vfio interface https://lore.kernel.org/kvm/0-v3-f7729924a7ea+25e33-vfio_kvm_no_group_jgg@n… - Simplify locking in vfio https://lore.kernel.org/kvm/0-v2-d035a1842d81+1bf-vfio_group_locking_jgg@nv… - Remove the vfio notifiter scheme that faces drivers https://lore.kernel.org/kvm/0-v4-681e038e30fd+78-vfio_unmap_notif_jgg@nvidi… - Improve the driver facing API for vfio pin/unpin pages to make the presence of struct page clear https://lore.kernel.org/kvm/20220723020256.30081-1-nicolinc@nvidia.com/ - Clean up in the Intel IOMMU driver https://lore.kernel.org/linux-iommu/20220301020159.633356-1-baolu.lu@linux.… https://lore.kernel.org/linux-iommu/20220510023407.2759143-1-baolu.lu@linux… https://lore.kernel.org/linux-iommu/20220514014322.2927339-1-baolu.lu@linux… https://lore.kernel.org/linux-iommu/20220706025524.2904370-1-baolu.lu@linux… https://lore.kernel.org/linux-iommu/20220702015610.2849494-1-baolu.lu@linux… - Rework s390 vfio drivers https://lore.kernel.org/kvm/20220707135737.720765-1-farman@linux.ibm.com/ - Normalize vfio ioctl handling https://lore.kernel.org/kvm/0-v2-0f9e632d54fb+d6-vfio_ioctl_split_jgg@nvidi… - VFIO API for dirty tracking (aka dma logging) managed inside a PCI device, with mlx5 implementation https://lore.kernel.org/kvm/20220901093853.60194-1-yishaih@nvidia.com - Introduce a struct device sysfs presence for struct vfio_device https://lore.kernel.org/kvm/20220901143747.32858-1-kevin.tian@intel.com/ - Complete restructuring the vfio mdev model https://lore.kernel.org/kvm/20220822062208.152745-1-hch@lst.de/ - Isolate VFIO container code in preperation for iommufd to provide an alternative implementation of it all https://lore.kernel.org/kvm/0-v1-a805b607f1fb+17b-vfio_container_split_jgg@… This is about 215 patches applied since March, thank you to everyone involved in all this work! Currently there are a number of supporting series still in progress: - Simplify and consolidate iommu_domain/device compatability checking https://lore.kernel.org/linux-iommu/20220815181437.28127-1-nicolinc@nvidia.… - Align iommu SVA support with the domain-centric model https://lore.kernel.org/linux-iommu/20220826121141.50743-1-baolu.lu@linux.i… - DMABUF exporter support for VFIO to allow PCI P2P with VFIO https://lore.kernel.org/r/0-v2-472615b3877e+28f7-vfio_dma_buf_jgg@nvidia.com - Start to provide iommu_domain ops for power https://lore.kernel.org/all/20220714081822.3717693-1-aik@ozlabs.ru/ However, these are not necessary for this series to advance. This is on github: https://github.com/jgunthorpe/linux/commits/iommufd v3: - Rebase to v6.1-rc1 - Improve documentation - Use EXPORT_SYMBOL_NS - Fix W1, checkpatch stuff - Revise pages.c to resolve the FIXMEs. Create a interval_tree_double_span_iter which allows a simple expression of the previously problematic algorithms - Consistently use the word 'access' instead of user to refer to an access from an in-kernel user (eg vfio mdev) - Support two forms of rlimit accounting and make the vfio compatible one the default in compatability mode (following series) - Support old VFIO type1 by disabling huge pages and implementing a simple algorithm to split a struct iopt_area - Full implementation of access support, test coverage and optimizations - Complete COPY to be able to copy across contiguous areas. Improve all the algorithms around contiguous areas with a dedicated iterator - Functional ENFORCED_COHERENT support - Support multi-device groups - Lots of smaller changes (the interdiff is 5k lines) v2: https://lore.kernel.org/r/0-v2-f9436d0bde78+4bb-iommufd_jgg@nvidia.com - Rebase to v6.0-rc3 - Improve comments - Change to an iterative destruction approach to avoid cycles - Near rewrite of the vfio facing implementation, supported by a complete implementation on the vfio side - New IOMMU_IOAS_ALLOW_IOVAS API as discussed. Allows userspace to assert that ranges of IOVA must always be mappable. To be used by a VMM that has promised a guest a certain availability of IOVA. May help guide PPC's multi-window implementation. - Rework how unmap_iova works, user can unmap the whole ioas now - The no-snoop / wbinvd support is implemented - Bug fixes - Test suite improvements - Lots of smaller changes (the interdiff is 3k lines) v1: https://lore.kernel.org/r/0-v1-e79cd8d168e8+6-iommufd_jgg@nvidia.com Jason Gunthorpe (13): iommu: Add IOMMU_CAP_ENFORCE_CACHE_COHERENCY interval-tree: Add a utility to iterate over spans in an interval tree iommufd: File descriptor, context, kconfig and makefiles kernel/user: Allow user::locked_vm to be usable for iommufd iommufd: PFN handling for iopt_pages iommufd: Algorithms for PFN storage iommufd: Data structure to provide IOVA to PFN mapping iommufd: IOCTLs for the io_pagetable iommufd: Add a HW pagetable object iommufd: Add kAPI toward external drivers for physical devices iommufd: Add kAPI toward external drivers for kernel access iommufd: vfio container FD ioctl compatibility iommufd: Add a selftest Kevin Tian (1): iommufd: Overview documentation Lu Baolu (1): iommu: Add device-centric DMA ownership interfaces .clang-format | 3 + Documentation/userspace-api/index.rst | 1 + .../userspace-api/ioctl/ioctl-number.rst | 1 + Documentation/userspace-api/iommufd.rst | 222 ++ MAINTAINERS | 10 + drivers/iommu/Kconfig | 1 + drivers/iommu/Makefile | 2 +- drivers/iommu/amd/iommu.c | 2 + drivers/iommu/intel/iommu.c | 4 + drivers/iommu/iommu.c | 116 +- drivers/iommu/iommufd/Kconfig | 24 + drivers/iommu/iommufd/Makefile | 13 + drivers/iommu/iommufd/device.c | 744 +++++++ drivers/iommu/iommufd/double_span.h | 98 + drivers/iommu/iommufd/hw_pagetable.c | 57 + drivers/iommu/iommufd/io_pagetable.c | 1143 +++++++++++ drivers/iommu/iommufd/io_pagetable.h | 240 +++ drivers/iommu/iommufd/ioas.c | 390 ++++ drivers/iommu/iommufd/iommufd_private.h | 273 +++ drivers/iommu/iommufd/iommufd_test.h | 85 + drivers/iommu/iommufd/main.c | 417 ++++ drivers/iommu/iommufd/pages.c | 1803 +++++++++++++++++ drivers/iommu/iommufd/selftest.c | 711 +++++++ drivers/iommu/iommufd/vfio_compat.c | 443 ++++ include/linux/interval_tree.h | 50 + include/linux/iommu.h | 18 + include/linux/iommufd.h | 101 + include/linux/sched/user.h | 2 +- include/uapi/linux/iommufd.h | 330 +++ kernel/user.c | 1 + lib/Kconfig | 4 + lib/interval_tree.c | 132 ++ tools/testing/selftests/Makefile | 1 + tools/testing/selftests/iommu/.gitignore | 2 + tools/testing/selftests/iommu/Makefile | 11 + tools/testing/selftests/iommu/config | 2 + tools/testing/selftests/iommu/iommufd.c | 1715 ++++++++++++++++ 37 files changed, 9145 insertions(+), 27 deletions(-) create mode 100644 Documentation/userspace-api/iommufd.rst create mode 100644 drivers/iommu/iommufd/Kconfig create mode 100644 drivers/iommu/iommufd/Makefile create mode 100644 drivers/iommu/iommufd/device.c create mode 100644 drivers/iommu/iommufd/double_span.h create mode 100644 drivers/iommu/iommufd/hw_pagetable.c create mode 100644 drivers/iommu/iommufd/io_pagetable.c create mode 100644 drivers/iommu/iommufd/io_pagetable.h create mode 100644 drivers/iommu/iommufd/ioas.c create mode 100644 drivers/iommu/iommufd/iommufd_private.h create mode 100644 drivers/iommu/iommufd/iommufd_test.h create mode 100644 drivers/iommu/iommufd/main.c create mode 100644 drivers/iommu/iommufd/pages.c create mode 100644 drivers/iommu/iommufd/selftest.c create mode 100644 drivers/iommu/iommufd/vfio_compat.c create mode 100644 include/linux/iommufd.h create mode 100644 include/uapi/linux/iommufd.h create mode 100644 tools/testing/selftests/iommu/.gitignore create mode 100644 tools/testing/selftests/iommu/Makefile create mode 100644 tools/testing/selftests/iommu/config create mode 100644 tools/testing/selftests/iommu/iommufd.c base-commit: 247f34f7b80357943234f93f247a1ae6b6c3a740 -- 2.38.0

2 years, 10 months

8
84
0 0

Słowa kluczowe do wypozycjonowania

by Adam Charachuta

Dzień dobry, zapoznałem się z Państwa ofertą i z przyjemnością przyznaję, że przyciąga uwagę i zachęca do dalszych rozmów. Pomyślałem, że może mógłbym mieć swój wkład w Państwa rozwój i pomóc dotrzeć z tą ofertą do większego grona odbiorców. Pozycjonuję strony www, dzięki czemu generują świetny ruch w sieci. Możemy porozmawiać w najbliższym czasie? Pozdrawiam Adam Charachuta

2 years, 10 months

1
0
0 0

[PATCH linux-next] selftests/vm: calculate variables in correct order

by Joel Savitz

commit b5ba705c2608 ("selftests/vm: enable running select groups of tests") unintentionally reversed the ordering of some of the lines of run_vmtests.sh that calculate values based on system configuration. Importantly, $hpgsize_MB is determined from $hpgsize_KB, but this later value is not read from /proc/meminfo until later, causing userfaultfd tests to incorrectly fail since $half_ufd_size_MB will always be 0. Switch these statements around into proper order to fix the invocation of the userfaultfd tests that use $half_ufd_size_MB. Suggested-by: Nico Pache <npache(a)redhat.com> Signed-off-by: Joel Savitz <jsavitz(a)redhat.com> --- tools/testing/selftests/vm/run_vmtests.sh | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/tools/testing/selftests/vm/run_vmtests.sh b/tools/testing/selftests/vm/run_vmtests.sh index fff00bb77086..ce52e4f5ff21 100755 --- a/tools/testing/selftests/vm/run_vmtests.sh +++ b/tools/testing/selftests/vm/run_vmtests.sh @@ -82,16 +82,6 @@ test_selected() { fi } -# Simple hugetlbfs tests have a hardcoded minimum requirement of -# huge pages totaling 256MB (262144KB) in size. The userfaultfd -# hugetlb test requires a minimum of 2 * nr_cpus huge pages. Take -# both of these requirements into account and attempt to increase -# number of huge pages available. -nr_cpus=$(nproc) -hpgsize_MB=$((hpgsize_KB / 1024)) -half_ufd_size_MB=$((((nr_cpus * hpgsize_MB + 127) / 128) * 128)) -needmem_KB=$((half_ufd_size_MB * 2 * 1024)) - # get huge pagesize and freepages from /proc/meminfo while read -r name size unit; do if [ "$name" = "HugePages_Free:" ]; then @@ -102,6 +92,16 @@ while read -r name size unit; do fi done < /proc/meminfo +# Simple hugetlbfs tests have a hardcoded minimum requirement of +# huge pages totaling 256MB (262144KB) in size. The userfaultfd +# hugetlb test requires a minimum of 2 * nr_cpus huge pages. Take +# both of these requirements into account and attempt to increase +# number of huge pages available. +nr_cpus=$(nproc) +hpgsize_MB=$((hpgsize_KB / 1024)) +half_ufd_size_MB=$((((nr_cpus * hpgsize_MB + 127) / 128) * 128)) +needmem_KB=$((half_ufd_size_MB * 2 * 1024)) + # set proper nr_hugepages if [ -n "$freepgs" ] && [ -n "$hpgsize_KB" ]; then nr_hugepgs=$(cat /proc/sys/vm/nr_hugepages) -- 2.31.1

2 years, 10 months

2
1
0 0

[PATCH v5 0/3] Implement IOCTL to get and/or the clear info about PTEs

by Muhammad Usama Anjum

Hello, This patch series implements IOCTL on the pagemap procfs file to get the information about the page table entries (PTEs). The following operations are supported in this ioctl: - Get the information if the pages are soft-dirty, file mapped, present or swapped. - Clear the soft-dirty PTE bit of the pages. - Get and clear the soft-dirty PTE bit of the pages atomically. Soft-dirty PTE bit of the memory pages can be read by using the pagemap procfs file. The soft-dirty PTE bit for the whole memory range of the process can be cleared by writing to the clear_refs file. There are other methods to mimic this information entirely in userspace with poor performance: - The mprotect syscall and SIGSEGV handler for bookkeeping - The userfaultfd syscall with the handler for bookkeeping Some benchmarks can be seen here[1]. This series adds features that weren't present earlier: - There is no atomic get soft-dirty PTE bit status and clear operation possible. - The soft-dirty PTE bit of only a part of memory cannot be cleared. Historically, soft-dirty PTE bit tracking has been used in the CRIU project. The procfs interface is enough for finding the soft-dirty bit status and clearing the soft-dirty bit of all the pages of a process. We have the use case where we need to track the soft-dirty PTE bit for only specific pages on demand. We need this tracking and clear mechanism of a region of memory while the process is running to emulate the getWriteWatch() syscall of Windows. This syscall is used by games to keep track of dirty pages to process only the dirty pages. The information related to pages if the page is file mapped, present and swapped is required for the CRIU project[2][3]. The addition of the required mask, any mask, excluded mask and return masks are also required for the CRIU project[2]. The IOCTL returns the addresses of the pages which match the specific masks. The page addresses are returned in struct page_region in a compact form. The max_pages is needed to support a use case where user only wants to get a specific number of pages. So there is no need to find all the pages of interest in the range when max_pages is specified. The IOCTL returns when the maximum number of the pages are found. The max_pages is optional. If max_pages is specified, it must be equal or greater than the vec_size. This restriction is needed to handle worse case when one page_region only contains info of one page and it cannot be compacted. This is needed to emulate the Windows getWriteWatch() syscall. Some non-dirty pages get marked as dirty because of the kernel's internal activity (such as VMA merging as soft-dirty bit difference isn't considered while deciding to merge VMAs). The dirty bit of the pages is stored in the VMA flags and in the per page flags. If any of these two bits are set, the page is considered to be soft dirty. Suppose you have cleared the soft dirty bit of half of VMA which will be done by splitting the VMA and clearing soft dirty bit flag in the half VMA and the pages in it. Now kernel may decide to merge the VMAs again. So the half VMA becomes dirty again. This splitting/merging costs performance. The application receives a lot of pages which aren't dirty in reality but marked as dirty. Performance is lost again here. Also sometimes user doesn't want the newly allocated memory to be marked as dirty. PAGEMAP_NO_REUSED_REGIONS flag solves both the problems. It is used to not depend on the soft dirty flag in the VMA flags. So VMA splitting and merging doesn't happen. It only depends on the soft dirty bit of the individual pages. Thus by using this flag, there may be a scenerio such that the new memory regions which are just created, doesn't look dirty when seen with the IOCTL, but look dirty when seen from procfs. This seems okay as the user of this flag know the implication of using it. [1] https://lore.kernel.org/lkml/54d4c322-cd6e-eefd-b161-2af2b56aae24@collabora… [2] https://lore.kernel.org/all/YyiDg79flhWoMDZB@gmail.com/ [3] https://lore.kernel.org/all/20221014134802.1361436-1-mdanylo@google.com/ Regards, Muhammad Usama Anjum Muhammad Usama Anjum (3): fs/proc/task_mmu: update functions to clear the soft-dirty PTE bit fs/proc/task_mmu: Implement IOCTL to get and/or the clear info about PTEs selftests: vm: add pagemap ioctl tests fs/proc/task_mmu.c | 396 +++++++++++- include/uapi/linux/fs.h | 53 ++ tools/include/uapi/linux/fs.h | 53 ++ tools/testing/selftests/vm/.gitignore | 1 + tools/testing/selftests/vm/Makefile | 5 +- tools/testing/selftests/vm/pagemap_ioctl.c | 681 +++++++++++++++++++++ 6 files changed, 1156 insertions(+), 33 deletions(-) create mode 100644 tools/testing/selftests/vm/pagemap_ioctl.c -- 2.30.2

2 years, 10 months

2
8
0 0

[PATCH] kselftest/arm64: fix array_size.cocci warning

by Kang Minchul

Use ARRAY_SIZE to fix the following coccicheck warnings: tools/testing/selftests/arm64/mte/check_buffer_fill.c:341:20-21: WARNING: Use ARRAY_SIZE tools/testing/selftests/arm64/mte/check_buffer_fill.c:35:20-21: WARNING: Use ARRAY_SIZE tools/testing/selftests/arm64/mte/check_buffer_fill.c:168:20-21: WARNING: Use ARRAY_SIZE tools/testing/selftests/arm64/mte/check_buffer_fill.c:72:20-21: WARNING: Use ARRAY_SIZE tools/testing/selftests/arm64/mte/check_buffer_fill.c:369:25-26: WARNING: Use ARRAY_SIZE Signed-off-by: Kang Minchul <tegongkang(a)gmail.com> --- .../testing/selftests/arm64/mte/check_buffer_fill.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/tools/testing/selftests/arm64/mte/check_buffer_fill.c b/tools/testing/selftests/arm64/mte/check_buffer_fill.c index 75fc482d63b6..1dbbbd47dd50 100644 --- a/tools/testing/selftests/arm64/mte/check_buffer_fill.c +++ b/tools/testing/selftests/arm64/mte/check_buffer_fill.c @@ -32,7 +32,7 @@ static int check_buffer_by_byte(int mem_type, int mode) bool err; mte_switch_mode(mode, MTE_ALLOW_NON_ZERO_TAG); - item = sizeof(sizes)/sizeof(int); + item = ARRAY_SIZE(sizes); for (i = 0; i < item; i++) { ptr = (char *)mte_allocate_memory(sizes[i], mem_type, 0, true); @@ -69,7 +69,7 @@ static int check_buffer_underflow_by_byte(int mem_type, int mode, char *und_ptr = NULL; mte_switch_mode(mode, MTE_ALLOW_NON_ZERO_TAG); - item = sizeof(sizes)/sizeof(int); + item = ARRAY_SIZE(sizes); for (i = 0; i < item; i++) { ptr = (char *)mte_allocate_memory_tag_range(sizes[i], mem_type, 0, underflow_range, 0); @@ -165,7 +165,7 @@ static int check_buffer_overflow_by_byte(int mem_type, int mode, char *over_ptr = NULL; mte_switch_mode(mode, MTE_ALLOW_NON_ZERO_TAG); - item = sizeof(sizes)/sizeof(int); + item = ARRAY_SIZE(sizes); for (i = 0; i < item; i++) { ptr = (char *)mte_allocate_memory_tag_range(sizes[i], mem_type, 0, 0, overflow_range); @@ -338,7 +338,7 @@ static int check_buffer_by_block(int mem_type, int mode) int i, item, result = KSFT_PASS; mte_switch_mode(mode, MTE_ALLOW_NON_ZERO_TAG); - item = sizeof(sizes)/sizeof(int); + item = ARRAY_SIZE(sizes); cur_mte_cxt.fault_valid = false; for (i = 0; i < item; i++) { result = check_buffer_by_block_iterate(mem_type, mode, sizes[i]); @@ -366,7 +366,7 @@ static int check_memory_initial_tags(int mem_type, int mode, int mapping) { char *ptr; int run, fd; - int total = sizeof(sizes)/sizeof(int); + int total = ARRAY_SIZE(sizes); mte_switch_mode(mode, MTE_ALLOW_NON_ZERO_TAG); for (run = 0; run < total; run++) { @@ -404,7 +404,7 @@ int main(int argc, char *argv[]) { int err; size_t page_size = getpagesize(); - int item = sizeof(sizes)/sizeof(int); + int item = ARRAY_SIZE(sizes); sizes[item - 3] = page_size - 1; sizes[item - 2] = page_size; -- 2.34.1

2 years, 10 months

2
1
0 0

[PATCH v1] kselftest/arm64: Remove validation of extra_context from TODO

by Mark Brown

When fixing up support for extra_context in the signal handling tests I didn't notice that there is a TODO file in the directory which lists this as a thing to be done. Since it's been done remove it from the list. Signed-off-by: Mark Brown <broonie(a)kernel.org> --- tools/testing/selftests/arm64/signal/testcases/TODO | 1 - 1 file changed, 1 deletion(-) diff --git a/tools/testing/selftests/arm64/signal/testcases/TODO b/tools/testing/selftests/arm64/signal/testcases/TODO index 110ff9fd195d..1f7fba8194fe 100644 --- a/tools/testing/selftests/arm64/signal/testcases/TODO +++ b/tools/testing/selftests/arm64/signal/testcases/TODO @@ -1,2 +1 @@ - Validate that register contents are saved and restored as expected. -- Support and validate extra_context. base-commit: 9abf2313adc1ca1b6180c508c25f22f9395cc780 -- 2.30.2

2 years, 10 months

2
1
0 0

[PATCH v1] kselftest/arm64: Print ASCII version of unknown signal frame magic values

by Mark Brown

The signal magic values are supposed to be allocated as somewhat meaningful ASCII so if we encounter a bad magic value print the any alphanumeric characters we find in it as well as the hex value to aid debuggability. Signed-off-by: Mark Brown <broonie(a)kernel.org> --- .../arm64/signal/testcases/testcases.c | 21 +++++++++++++++---- 1 file changed, 17 insertions(+), 4 deletions(-) diff --git a/tools/testing/selftests/arm64/signal/testcases/testcases.c b/tools/testing/selftests/arm64/signal/testcases/testcases.c index e1c625b20ac4..d2eda7b5de26 100644 --- a/tools/testing/selftests/arm64/signal/testcases/testcases.c +++ b/tools/testing/selftests/arm64/signal/testcases/testcases.c @@ -1,5 +1,9 @@ // SPDX-License-Identifier: GPL-2.0 /* Copyright (C) 2019 ARM Limited */ + +#include <ctype.h> +#include <string.h> + #include "testcases.h" struct _aarch64_ctx *get_header(struct _aarch64_ctx *head, uint32_t magic, @@ -109,7 +113,7 @@ bool validate_reserved(ucontext_t *uc, size_t resv_sz, char **err) bool terminated = false; size_t offs = 0; int flags = 0; - int new_flags; + int new_flags, i; struct extra_context *extra = NULL; struct sve_context *sve = NULL; struct za_context *za = NULL; @@ -117,6 +121,7 @@ bool validate_reserved(ucontext_t *uc, size_t resv_sz, char **err) (struct _aarch64_ctx *)uc->uc_mcontext.__reserved; void *extra_data = NULL; size_t extra_sz = 0; + char magic[4]; if (!err) return false; @@ -194,11 +199,19 @@ bool validate_reserved(ucontext_t *uc, size_t resv_sz, char **err) /* * A still unknown Magic: potentially freshly added * to the Kernel code and still unknown to the - * tests. + * tests. Magic numbers are supposed to be allocated + * as somewhat meaningful ASCII strings so try to + * print as such as well as the raw number. */ + memcpy(magic, &head->magic, sizeof(magic)); + for (i = 0; i < sizeof(magic); i++) + if (!isalnum(magic[i])) + magic[i] = '?'; + fprintf(stdout, - "SKIP Unknown MAGIC: 0x%X - Is KSFT arm64/signal up to date ?\n", - head->magic); + "SKIP Unknown MAGIC: 0x%X (%c%c%c%c) - Is KSFT arm64/signal up to date ?\n", + head->magic, + magic[3], magic[2], magic[1], magic[0]); break; } base-commit: 30a0b95b1335e12efef89dd78518ed3e4a71a763 -- 2.30.2

2 years, 10 months

2
1
0 0

[PATCH v1 0/2] kselftest/arm64: fp-stress output clarity improvements

by Mark Brown

This series provides a couple of improvements to the output of fp-stress, making it easier to follow what's going on and our application of the timeout a bit more even. Mark Brown (2): kselftest/arm64: Check that all children are producing output in fp-stress kselftest/arm64: Provide progress messages when signalling children tools/testing/selftests/arm64/fp/fp-stress.c | 26 ++++++++++++++++++++ 1 file changed, 26 insertions(+) base-commit: 9abf2313adc1ca1b6180c508c25f22f9395cc780 -- 2.30.2

2 years, 10 months

2
3
0 0

Re: [PATCH v2] [RFC] selftests: alsa - add PCM test

by Mark Brown

On Tue, Nov 08, 2022 at 12:59:14PM +0100, Jaroslav Kysela wrote: > This initial code does a simple sample transfer tests. By default, > all PCM devices are detected and tested with short and long > buffering parameters for 4 seconds. If the sample transfer timing > is not in a +-100ms boundary, the test fails. Only the interleaved > buffering scheme is supported in this version. Oh, thanks for picking this up - something like this has been on my mind for ages! This should probably be copied to Shuah and the kselftest list as well, I've added them. This looks basically good to me, I've got a bunch of comments below but I'm not sure any of them except possibly the one about not putting values in the configuration file by default should block getting this merged so: Reviewed-by: Mark Brown <broonie(a)kernel.org> > The configuration may be modified with the configuration files. > A specific hardware configuration is detected and activated > using the sysfs regex matching. This allows to use the DMI string > (/sys/class/dmi/id/* tree) or any other system parameters > exposed in sysfs for the matching for the CI automation. > The configuration file may also specify the PCM device list to detect > the missing PCM devices. > create mode 100644 tools/testing/selftests/alsa/alsa-local.h > create mode 100644 tools/testing/selftests/alsa/conf.c > create mode 100644 tools/testing/selftests/alsa/conf.d/Lenovo_ThinkPad_P1_Gen2.conf > create mode 100644 tools/testing/selftests/alsa/pcm-test.c This is a bit unusual for kselftest and might create a bit of churn but does seem sensible and reasonable to me, it's on the edge of what kselftest usually covers but seems close enough in scope. I worry a bit about ending up needing to add a config fragment as a result but perhaps we can get away without. > index 000000000000..0a83f35d43eb > --- /dev/null > +++ b/tools/testing/selftests/alsa/conf.d/Lenovo_ThinkPad_P1_Gen2.conf > + pcm.0.0 { > + PLAYBACK { > + test.time1 { > + access RW_INTERLEAVED # can be omitted - default > + format S16_LE # can be omitted - default > + rate 48000 # can be omitted - default > + channels 2 # can be omitted - default > + period_size 512 > + buffer_size 4096 I think it'd be better to leave these commented by default, especially if/once we improve the enumeration. That way the coverage will default to whatever the tool does by default on the system (including any checking of constraints for example). I guess we might want to add a way of saying "here's what I expect the constraints to be" but that's very much future work. > +#ifdef SND_LIB_VER > +#if SND_LIB_VERSION >= SND_LIB_VER(1, 2, 6) > +#define LIB_HAS_LOAD_STRING > +#endif > +#endif > + > +#ifndef LIB_HAS_LOAD_STRING > +static int snd_config_load_string(snd_config_t **config, const char *s, > + size_t size) > +{ This is also in mixer-test, we should pull it into a helper library too. Something that could be done separately/incrementally. > + for (i = 0; i < 4; i++) { > + > + snd_pcm_drain(handle); > + ms = timestamp_diff_ms(&tstamp); > + if (ms < 3900 || ms > 4100) { It feels like the runtime might be usefully parameterised here - there's a tradeoff with detecting inaccurate clocks and runtime that people might want to make. > + ksft_set_plan(num_missing + num_pcms * TESTS_PER_PCM); > + for (pcm = pcm_missing; pcm != NULL; pcm = pcm->next) { > + ksft_test_result(false, "test.missing.%d.%d.%d.%s\n", > + pcm->card, pcm->device, pcm->subdevice, > + snd_pcm_stream_name(pcm->stream)); > + } We don't seem to report a successful test.missing anywhere like find_pcms() so if we ever hit a test.missing then it'll look like a new test, old test runs won't have logged the failure. That can change how people look at any failures that crop up, "it's new and never worked" is different to "this used to work" and people are likely to just be running kselftest rather than specifically know this test. It'd be better if we counted the cards in the config and used that for our expected number of test.missings, logging cards that we find here as well. > + for (pcm = pcm_list; pcm != NULL; pcm = pcm->next) { > + test_pcm_time1(pcm, "test.time1", "S16_LE", 48000, 2, 512, 4096); > + test_pcm_time1(pcm, "test.time2", "S16_LE", 48000, 2, 24000, 192000); > + } It does feel like especially in the case where no configuration is specified we should be eumerating what the card can do and both potentially doing more tests (though there's obviously an execution time tradeoff with going overboard there) and skipping configurations that the card never claimed to support in the first place. In particular I'm expecting we'll see some cards that only do either 44.1kHz or 48kHz and will get spurious fails by default, and I'd like to see coverage of mono playback on cards that claim to support it because I suspect there's a bunch of them that don't actually do the right thing. Like I say most of this could be done incrementally if we decide it needs to get done at all though, we shouldn't let perfect be the enemy of good.

2 years, 10 months

1
0
0 0

Greeting

by Mr.Abraham

My Greeting, Did you receive the letter i sent to you. Please answer me. Regard, Mr.Abraham

2 years, 10 months

1
0
0 0

Re: [PATCH v4 15/17] iommufd: Add a selftest

by Nicolin Chen

On Mon, Nov 07, 2022 at 08:49:08PM -0400, Jason Gunthorpe wrote: > diff --git a/tools/testing/selftests/iommu/iommufd.c b/tools/testing/selftests/iommu/iommufd.c > +TEST_F(iommufd, cmd_length) > +{ > +#define TEST_LENGTH(_struct, _ioctl) \ > + { \ > + struct { \ > + struct _struct cmd; \ > + uint8_t extra; \ > + } cmd = { .cmd = { .size = sizeof(struct _struct) - 1 }, \ > + .extra = UINT8_MAX }; \ > + int old_errno; \ > + int rc; \ > + \ > + EXPECT_ERRNO(EOPNOTSUPP, ioctl(self->fd, _ioctl, &cmd)); \ I guess it should be EINVAL corresponding to updated kernel code? > +TEST_F(iommufd, cmd_ex_fail) > +{ > + struct { > + struct iommu_destroy cmd; > + __u64 future; > + } cmd = { .cmd = { .size = sizeof(cmd), .id = 0 } }; > + > + /* object id is invalid and command is longer */ > + EXPECT_ERRNO(ENOENT, ioctl(self->fd, IOMMU_DESTROY, &cmd)); > + /* future area is non-zero */ > + cmd.future = 1; > + EXPECT_ERRNO(E2BIG, ioctl(self->fd, IOMMU_DESTROY, &cmd)); > + /* Original command "works" */ > + cmd.cmd.size = sizeof(cmd.cmd); > + EXPECT_ERRNO(ENOENT, ioctl(self->fd, IOMMU_DESTROY, &cmd)); > + /* Short command fails */ > + cmd.cmd.size = sizeof(cmd.cmd) - 1; > + EXPECT_ERRNO(EOPNOTSUPP, ioctl(self->fd, IOMMU_DESTROY, &cmd)); Ditto > +TEST_HARNESS_MAIN > diff --git a/tools/testing/selftests/iommu/iommufd_fail_nth.c b/tools/testing/selftests/iommu/iommufd_fail_nth.c > +static void fail_nth_first(struct __test_metadata *_metadata, > + struct fail_nth_state *nth_state) > +{ > + char buf[300]; > + > + snprintf(buf, sizeof(buf), "/proc/self/task/%u/fail-nth", gettid()); Not sure what's missing, I have a build error at gettid. Copying a solution from tools/perf/jvmti/jvmti_agent.c file, can fix with: ------------------------------ diff --git a/tools/testing/selftests/iommu/iommufd_fail_nth.c b/tools/testing/selftests/iommu/iommufd_fail_nth.c index 99eaa9f32e0b..7704b3a754d3 100644 --- a/tools/testing/selftests/iommu/iommufd_fail_nth.c +++ b/tools/testing/selftests/iommu/iommufd_fail_nth.c @@ -19,6 +19,7 @@ #define __EXPORTED_HEADERS__ #include <linux/vfio.h> +#include <syscall.h> /* for gettid() */ #include "iommufd_utils.h" @@ -84,6 +85,13 @@ struct fail_nth_state { unsigned int iteration; }; +#ifndef HAVE_GETTID +static inline pid_t gettid(void) +{ + return (pid_t)syscall(__NR_gettid); +} +#endif + static void fail_nth_first(struct __test_metadata *_metadata, struct fail_nth_state *nth_state) { ------------------------------

2 years, 10 months

2
1
0 0

[PATCH] selftests: cgroup: Fix unsigned comparison with less than zero

by YueHaibing

'size' is unsigned, it never less than zero. Fixes: 6c26df84e1f2 ("selftests: cgroup: return -errno from cg_read()/cg_write() on failure") Signed-off-by: YueHaibing <yuehaibing(a)huawei.com> --- tools/testing/selftests/cgroup/cgroup_util.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/cgroup/cgroup_util.c b/tools/testing/selftests/cgroup/cgroup_util.c index 4c52cc6f2f9c..e8bbbdb77e0d 100644 --- a/tools/testing/selftests/cgroup/cgroup_util.c +++ b/tools/testing/selftests/cgroup/cgroup_util.c @@ -555,6 +555,7 @@ int proc_mount_contains(const char *option) ssize_t proc_read_text(int pid, bool thread, const char *item, char *buf, size_t size) { char path[PATH_MAX]; + ssize_t ret; if (!pid) snprintf(path, sizeof(path), "/proc/%s/%s", @@ -562,8 +563,8 @@ ssize_t proc_read_text(int pid, bool thread, const char *item, char *buf, size_t else snprintf(path, sizeof(path), "/proc/%d/%s", pid, item); - size = read_text(path, buf, size); - return size < 0 ? -1 : size; + ret = read_text(path, buf, size); + return ret < 0 ? -1 : ret; } int proc_read_strstr(int pid, bool thread, const char *item, const char *needle) -- 2.17.1

2 years, 10 months

5
4
0 0

selftests: clone3: clone3_clear_sighand failed - Bail out! Failed to clear signal handler for child process

by Naresh Kamboju

selftests: clone3: clone3_clear_sighand failed on arm32 and i386 but passed on arm64 and x86_64. Reported-by: Linux Kernel Functional Testing <lkft(a)linaro.org> # selftests: clone3: clone3_clear_sighand # TAP version 13 # 1..1 # # clone3() syscall supported # Bail out! Failed to clear signal handler for child process # # Planned tests != run tests (1 != 0) # # Totals: pass:0 fail:0 xfail:0 xpass:0 skip:0 error:0 not ok 2 selftests: clone3: clone3_clear_sighand # exit=1 Test details links, https://lkft.validation.linaro.org/scheduler/job/5820146#L1795 Test results comparison link, https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20221107/te… metadata: git_ref: master git_repo: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next git_sha: b6fc3fddade7a194bd141a49f2689e50f796ef46 git_describe: next-20221108 kernel_version: 6.1.0-rc4 kernel-config: https://builds.tuxbuild.com/2HFnr3jvzSvcbeO3iSMp7Fbvmmq/config build-url: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next/-/pipelines/688275399 artifact-location: https://builds.tuxbuild.com/2HFnr3jvzSvcbeO3iSMp7Fbvmmq toolchain: gcc-11 -- Linaro LKFT https://lkft.linaro.org

2 years, 10 months

3
5
0 0

[PATCH 0/4] bpf: Support kernel function call in 32-bit ARM

by Yang Jihong

1. Patch 1 and Patch 2 are dependent patches to resolve the BPF check error in 32-bit ARM. 2. Patch 3 supports bpf fkunc in 32-bit ARM. 3. Patch 4 is used to add test cases to cover some parameter scenarios states by AAPCS. The following is the test_progs result in the 32-bit ARM environment: # uname -a Linux qemuarm32 6.1.0-rc3+ #2 SMP Thu Nov 3 15:31:29 CST 2022 armv7l armv7l armv7l GNU/Linux # echo 1 > /proc/sys/net/core/bpf_jit_enable # ./test_progs -t kfunc_call #1/1 kfunc_call/kfunc_syscall_test_fail:OK #1/2 kfunc_call/kfunc_syscall_test_null_fail:OK #1/3 kfunc_call/kfunc_call_test_get_mem_fail_rdonly:OK #1/4 kfunc_call/kfunc_call_test_get_mem_fail_use_after_free:OK #1/5 kfunc_call/kfunc_call_test_get_mem_fail_oob:OK #1/6 kfunc_call/kfunc_call_test_get_mem_fail_not_const:OK #1/7 kfunc_call/kfunc_call_test_mem_acquire_fail:OK #1/8 kfunc_call/kfunc_call_test1:OK #1/9 kfunc_call/kfunc_call_test2:OK #1/10 kfunc_call/kfunc_call_test4:OK #1/11 kfunc_call/kfunc_call_test_ref_btf_id:OK #1/12 kfunc_call/kfunc_call_test_get_mem:OK #1/13 kfunc_call/kfunc_syscall_test:OK #1/14 kfunc_call/kfunc_syscall_test_null:OK #1/17 kfunc_call/destructive:OK Yang Jihong (4): bpf: Adapt 32-bit return value kfunc for 32-bit ARM when zext extension bpf: Remove size check for sk in bpf_skb_is_valid_access for 32-bit architecture bpf: Add kernel function call support in 32-bit ARM bpf:selftests: Add kfunc_call test for mixing 32-bit and 64-bit parameters arch/arm/net/bpf_jit_32.c | 130 ++++++++++++++++++ kernel/bpf/verifier.c | 3 + net/bpf/test_run.c | 6 + net/core/filter.c | 2 - .../selftests/bpf/prog_tests/kfunc_call.c | 1 + .../selftests/bpf/progs/kfunc_call_test.c | 23 ++++ 6 files changed, 163 insertions(+), 2 deletions(-) -- 2.30.GIT

2 years, 10 months

4
8
0 0

Re: [PATCH v4 15/17] iommufd: Add a selftest

by Jason Gunthorpe

On Mon, Nov 07, 2022 at 08:49:08PM -0400, Jason Gunthorpe wrote: > Cover the essential functionality of the iommufd with a directed > test. This aims to achieve reasonable functional coverage using the > in-kernel self test framework. > > It provides a mock kernel module for the iommu_domain that allows it to > run without any HW and the mocking provides a way to directly validate > that the PFNs loaded into the iommu_domain are correct. > > The mock also simulates the rare case of PAGE_SIZE > iommu page size as > the mock will operate at a 2K iommu page size. This allows exercising all > of the calculations to support this mismatch. > > This allows achieving high coverage of the corner cases in the iopt_pages. > > However, it is an unusually invasive config option to enable all of > this. The config option should not be enabled in a production kernel. This patch crossed 100k so it was bounced from the vger lists. If anyone didn't get it and would like to see it lore has it: https://lore.kernel.org/linux-iommu/15-v4-0de2f6c78ed0+9d1-iommufd_jgg@nvid… For the eventual v5 I will split the nth test into its own patch Jason

2 years, 10 months

1
0
0 0

[net] seg6: selftests/bpf: fix BPF object file name in test_lwt_seg6local.sh

by Andrea Mayer

The test_lwt_seg6local.c implements several eBPF programs which are used to test the SRv6 End.BPF behavior. Since commit afef88e65554 ("selftests/bpf: Store BPF object files with .bpf.o extension"), part of the build system and test programs loading BPF object files are supposed to work with the .bpf.o extension. Consequently, the test_lwt_seg6local.c is compiled into test_lwt_seg6local.bpf.o and the corresponding test_lwt_seg6local.sh script is not updated to deal with the correct .bpf.o extension. This patch fixes the test_lwt_seg6local.sh, using the correct .bpf.o extension for the testing BPF object file, i.e. test_lwt_seg6local.bpf.o. Fixes: afef88e65554 ("selftests/bpf: Store BPF object files with .bpf.o extension") Signed-off-by: Andrea Mayer <andrea.mayer(a)uniroma2.it> --- tools/testing/selftests/bpf/test_lwt_seg6local.sh | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/tools/testing/selftests/bpf/test_lwt_seg6local.sh b/tools/testing/selftests/bpf/test_lwt_seg6local.sh index 826f4423ce02..bfe76ab78481 100755 --- a/tools/testing/selftests/bpf/test_lwt_seg6local.sh +++ b/tools/testing/selftests/bpf/test_lwt_seg6local.sh @@ -117,18 +117,18 @@ ip netns exec ${NS6} ip -6 addr add fb00::109/16 dev veth10 scope link ip netns exec ${NS1} ip -6 addr add fb00::1/16 dev lo ip netns exec ${NS1} ip -6 route add fb00::6 dev veth1 via fb00::21 -ip netns exec ${NS2} ip -6 route add fb00::6 encap bpf in obj test_lwt_seg6local.o sec encap_srh dev veth2 +ip netns exec ${NS2} ip -6 route add fb00::6 encap bpf in obj test_lwt_seg6local.bpf.o sec encap_srh dev veth2 ip netns exec ${NS2} ip -6 route add fd00::1 dev veth3 via fb00::43 scope link ip netns exec ${NS3} ip -6 route add fc42::1 dev veth5 via fb00::65 -ip netns exec ${NS3} ip -6 route add fd00::1 encap seg6local action End.BPF endpoint obj test_lwt_seg6local.o sec add_egr_x dev veth4 +ip netns exec ${NS3} ip -6 route add fd00::1 encap seg6local action End.BPF endpoint obj test_lwt_seg6local.bpf.o sec add_egr_x dev veth4 -ip netns exec ${NS4} ip -6 route add fd00::2 encap seg6local action End.BPF endpoint obj test_lwt_seg6local.o sec pop_egr dev veth6 +ip netns exec ${NS4} ip -6 route add fd00::2 encap seg6local action End.BPF endpoint obj test_lwt_seg6local.bpf.o sec pop_egr dev veth6 ip netns exec ${NS4} ip -6 addr add fc42::1 dev lo ip netns exec ${NS4} ip -6 route add fd00::3 dev veth7 via fb00::87 ip netns exec ${NS5} ip -6 route add fd00::4 table 117 dev veth9 via fb00::109 -ip netns exec ${NS5} ip -6 route add fd00::3 encap seg6local action End.BPF endpoint obj test_lwt_seg6local.o sec inspect_t dev veth8 +ip netns exec ${NS5} ip -6 route add fd00::3 encap seg6local action End.BPF endpoint obj test_lwt_seg6local.bpf.o sec inspect_t dev veth8 ip netns exec ${NS6} ip -6 addr add fb00::6/16 dev lo ip netns exec ${NS6} ip -6 addr add fd00::4/16 dev lo -- 2.20.1

2 years, 10 months

4
3
0 0

[PATCH v2 0/2] Fix slab-out-of-bounds Write in dbgfs_rm_context_write

by SeongJae Park

Changes from v1 (https://lore.kernel.org/damon/20221031182554.7882-1-sj@kernel.org/) - Rebase on latest mm-unstable --- This patchset is for fixing (patch 1) the syzbot-reported slab-out-of-bounds write in dbgfs_rm_context_write[1], and adding a selftest for the bug (patch 2). [1] https://lore.kernel.org/damon/000000000000ede3ac05ec4abf8e@google.com/ SeongJae Park (2): mm/damon/dbgfs: check if rm_contexts input is for a real context selftests/damon: test non-context inputs to rm_contexts file mm/damon/dbgfs.c | 7 +++++++ tools/testing/selftests/damon/Makefile | 1 + .../damon/debugfs_rm_non_contexts.sh | 19 +++++++++++++++++++ 3 files changed, 27 insertions(+) create mode 100755 tools/testing/selftests/damon/debugfs_rm_non_contexts.sh -- 2.25.1

2 years, 10 months

1
1
0 0

[RESEND][RFC][PATCH 1/3] lsm: Clarify documentation of vm_enough_memory hook

by Roberto Sassu

From: Roberto Sassu <roberto.sassu(a)huawei.com> include/linux/lsm_hooks.h reports the result of the LSM infrastructure to the callers, not what LSMs should return to the LSM infrastructure. Clarify that and add that returning 1 from the LSMs means calling __vm_enough_memory() with cap_sys_admin set, 0 without. Signed-off-by: Roberto Sassu <roberto.sassu(a)huawei.com> --- include/linux/lsm_hooks.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h index 4ec80b96c22e..f40b82ca91e7 100644 --- a/include/linux/lsm_hooks.h +++ b/include/linux/lsm_hooks.h @@ -1411,7 +1411,9 @@ * Check permissions for allocating a new virtual mapping. * @mm contains the mm struct it is being added to. * @pages contains the number of pages. - * Return 0 if permission is granted. + * Return 0 if permission is granted by LSMs to the caller. LSMs should + * return 1 if __vm_enough_memory() should be called with + * cap_sys_admin set, 0 if not. * * @ismaclabel: * Check if the extended attribute specified by @name -- 2.25.1

2 years, 10 months

3
9
0 0

Re:

by Mrs. Monika Everenová

Hei ja miten voit? Nimeni on rouva Evereen, lähetän tämän viestin suurella toivolla välitön vastaus, koska minun on tehtävä uusi sydänleikkaus tällä hetkellä huonokuntoinen ja vähäiset mahdollisuudet selviytyä. Mutta ennen kuin minä Tee toinen vaarallinen operaatio, annan sen sinulle Minulla on 6 550 000 dollaria yhdysvaltalaisella pankkitilillä sijoittamista, hallinnointia ja käyttöä varten voittoa hyväntekeväisyysprojektin toteuttamiseen. Tarkoitan sairaiden auttamista ja köyhät ovat viimeinen haluni maan päällä, sillä minulla ei ole niitä keneltä perii rahaa. Vastaa minulle nopeasti terveisiä Rouva Monika Evereen Florida, Amerikan Yhdysvallat ======================================================= Hi and how are you? My name is Mrs. Evereen, I am sending this message with great hope for an immediate response, as I have to undergo heart reoperation in my current poor health with little chance of survival. But before I undertake the second dangerous operation, I will give you the $6,550,000 I have in my US bank account to invest well, manage and use the profits to run a charity project for me. I count helping the sick and the poor as my last wish on earth, because I have no one to inherit money from. Please give me a quick reply regards Mrs. Monika Evereen Florida, United States of America

2 years, 10 months

1
0
0 0

[PATCH bpf RESEND 0/4] bpf: Support kernel function call in 32-bit ARM

by Yang Jihong

1. Patch 1 and Patch 2 are dependent patches to resolve the BPF check error in 32-bit ARM. 2. Patch 3 supports bpf fkunc in 32-bit ARM. 3. Patch 4 is used to add test cases to cover some parameter scenarios states by AAPCS. The following is the test_progs result in the 32-bit ARM environment: # uname -a Linux qemuarm32 6.1.0-rc3+ #2 SMP Thu Nov 3 15:31:29 CST 2022 armv7l armv7l armv7l GNU/Linux # echo 1 > /proc/sys/net/core/bpf_jit_enable # ./test_progs -t kfunc_call #1/1 kfunc_call/kfunc_syscall_test_fail:OK #1/2 kfunc_call/kfunc_syscall_test_null_fail:OK #1/3 kfunc_call/kfunc_call_test_get_mem_fail_rdonly:OK #1/4 kfunc_call/kfunc_call_test_get_mem_fail_use_after_free:OK #1/5 kfunc_call/kfunc_call_test_get_mem_fail_oob:OK #1/6 kfunc_call/kfunc_call_test_get_mem_fail_not_const:OK #1/7 kfunc_call/kfunc_call_test_mem_acquire_fail:OK #1/8 kfunc_call/kfunc_call_test1:OK #1/9 kfunc_call/kfunc_call_test2:OK #1/10 kfunc_call/kfunc_call_test4:OK #1/11 kfunc_call/kfunc_call_test_ref_btf_id:OK #1/12 kfunc_call/kfunc_call_test_get_mem:OK #1/13 kfunc_call/kfunc_syscall_test:OK #1/14 kfunc_call/kfunc_syscall_test_null:OK #1/17 kfunc_call/destructive:OK Yang Jihong (4): bpf: Adapt 32-bit return value kfunc for 32-bit ARM when zext extension bpf: Remove size check for sk in bpf_skb_is_valid_access for 32-bit architecture bpf: Add kernel function call support in 32-bit ARM bpf:selftests: Add kfunc_call test for mixing 32-bit and 64-bit parameters arch/arm/net/bpf_jit_32.c | 130 ++++++++++++++++++ kernel/bpf/verifier.c | 3 + net/bpf/test_run.c | 6 + net/core/filter.c | 2 - .../selftests/bpf/prog_tests/kfunc_call.c | 1 + .../selftests/bpf/progs/kfunc_call_test.c | 23 ++++ 6 files changed, 163 insertions(+), 2 deletions(-) -- 2.30.GIT

2 years, 10 months

4
12
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror