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

[arm] lib: bitmap.sh: BUG: KFENCE: out-of-bounds read in _find_next_bit_le+0x10/0x48

by Naresh Kamboju

Following kernel BUG KFENCE noticed on qemu_arm while testing lib: bitmap.sh with kselftest merge config build image [1] & [2]. metadata: git_ref: master git_repo: https://gitlab.com/Linaro/lkft/mirrors/torvalds/linux-mainline git_sha: 672c0c5173427e6b3e2a9bbb7be51ceeec78093a git_describe: v5.18-rc5 kernel_version: 5.18.0-rc5 kernel-config: https://builds.tuxbuild.com/28a2wdk3XzmLVGqD5njLS4uX1tm/config artifact-location: https://builds.tuxbuild.com/28a2wdk3XzmLVGqD5njLS4uX1tm toolchain: gcc-10 Test log: --------- # selftests: lib: bitmap.sh [ 36.266913] test_bitmap: loaded. [ 36.269151] test_bitmap: parselist: 14: input is '0-2047:128/256' OK, Time: 4600 [ 36.273024] ================================================================== [ 36.275942] BUG: KFENCE: out-of-bounds read in _find_next_bit_le+0x10/0x48 [ 36.275942] [ 36.279808] Out-of-bounds read at 0x9ec8e937 (4096B right of kfence-#29): [ 36.283046] _find_next_bit_le+0x10/0x48 [ 36.285030] [ 36.285816] kfence-#29: 0xf28dd28d-0x0b305c8e, size=4096, cache=kmalloc-4k [ 36.285816] [ 36.289807] allocated by task 498 on cpu 1 at 36.272960s: [ 36.292432] test_bitmap_printlist+0x2c/0x13c [test_bitmap] [ 36.295174] test_bitmap_init+0x5c/0xefc [test_bitmap] [ 36.297709] do_one_initcall+0x70/0x330 [ 36.299605] do_init_module+0x4c/0x26c [ 36.301484] sys_finit_module+0xdc/0x138 [ 36.303452] ret_fast_syscall+0x0/0x1c [ 36.305294] 0xbebec788 [ 36.306516] [ 36.307264] CPU: 1 PID: 498 Comm: modprobe Not tainted 5.18.0-rc5 #1 [ 36.310304] Hardware name: Generic DT based system [ 36.312658] ================================================================== [ 36.316609] test_bitmap: bitmap_print_to_pagebuf: input is '0-32767 [ 36.316609] ', Time: 43635540 [ 36.333605] test_bitmap: all 1945 tests passed [ 36.360116] test_bitmap: unloaded. # bitmap: ok Reported-by: Linux Kernel Functional Testing <lkft(a)linaro.org> -- Linaro LKFT https://lkft.linaro.org [1] https://lkft.validation.linaro.org/scheduler/job/4975877#L995 [2] https://qa-reports.linaro.org/lkft/linux-mainline-master/build/v5.18-rc5/te…

2 years, 9 months

1
0
0 0

[PATCH v2 0/2] Dirtying, failing memop: don't indicate suppression

by Janis Schoetterl-Glausch

If a memop fails due to key checked protection, after already having written to the guest, don't indicate suppression to the guest, as that would imply that memory wasn't modified. This could be considered a fix to the code introducing storage key support, however this is a bug in KVM only if we emulate an instructions writing to an operand spanning multiple pages, which I don't believe we do. v1 -> v2 * Reword commit message of patch 1 Janis Schoetterl-Glausch (2): KVM: s390: Don't indicate suppression on dirtying, failing memop KVM: s390: selftest: Test suppression indication on key prot exception arch/s390/kvm/gaccess.c | 47 ++++++++++++++--------- tools/testing/selftests/kvm/s390x/memop.c | 43 ++++++++++++++++++++- 2 files changed, 70 insertions(+), 20 deletions(-) base-commit: af2d861d4cd2a4da5137f795ee3509e6f944a25b -- 2.32.0

2 years, 9 months

4
16
0 0

<> unique domains links <>

by Mark

Hi, When you get 1000 unique domains you get links from only unique domains with unique ips https://www.creative-digital.co/product/unique-domains-links/ Unsubscribe: https://mgdots.co/unsubscribe/

2 years, 9 months

1
0
0 0

[PATCH v2 1/4] kunit: rename print_subtest_{start,end} for clarity (s/subtest/suite)

by Daniel Latypov

These names sound more general than they are. The _end() function increments a `static int kunit_suite_counter`, so it can only safely be called on suites, aka top-level subtests. It would need to have a separate counter for each level of subtest to be generic enough. So rename it to make it clear it's only appropriate for suites. Signed-off-by: Daniel Latypov <dlatypov(a)google.com> Reviewed-by: David Gow <davidgow(a)google.com> --- v1 -> v2: no change (see patch 2 and 4) --- lib/kunit/test.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/lib/kunit/test.c b/lib/kunit/test.c index 0f66c13d126e..64ee6a9d8003 100644 --- a/lib/kunit/test.c +++ b/lib/kunit/test.c @@ -134,7 +134,7 @@ size_t kunit_suite_num_test_cases(struct kunit_suite *suite) } EXPORT_SYMBOL_GPL(kunit_suite_num_test_cases); -static void kunit_print_subtest_start(struct kunit_suite *suite) +static void kunit_print_suite_start(struct kunit_suite *suite) { kunit_log(KERN_INFO, suite, KUNIT_SUBTEST_INDENT "# Subtest: %s", suite->name); @@ -192,7 +192,7 @@ EXPORT_SYMBOL_GPL(kunit_suite_has_succeeded); static size_t kunit_suite_counter = 1; -static void kunit_print_subtest_end(struct kunit_suite *suite) +static void kunit_print_suite_end(struct kunit_suite *suite) { kunit_print_ok_not_ok((void *)suite, false, kunit_suite_has_succeeded(suite), @@ -498,7 +498,7 @@ int kunit_run_tests(struct kunit_suite *suite) struct kunit_result_stats suite_stats = { 0 }; struct kunit_result_stats total_stats = { 0 }; - kunit_print_subtest_start(suite); + kunit_print_suite_start(suite); kunit_suite_for_each_test_case(suite, test_case) { struct kunit test = { .param_value = NULL, .param_index = 0 }; @@ -552,7 +552,7 @@ int kunit_run_tests(struct kunit_suite *suite) } kunit_print_suite_stats(suite, suite_stats, total_stats); - kunit_print_subtest_end(suite); + kunit_print_suite_end(suite); return 0; } base-commit: 59729170afcd4900e08997a482467ffda8d88c7f -- 2.36.0.464.gb9c8b46e94-goog

2 years, 9 months

2
7
0 0

[PATCH 1/3] kunit: rename print_subtest_{start,end} for clarity (s/subtest/suite)

by Daniel Latypov

These names sound more general than they are. The _end() function increments a `static int kunit_suite_counter`, so it can only safely be called on suites, aka top-level subtests. It would need to have a separate counter for each level of subtest to be generic enough. So rename it to make it clear it's only appropriate for suites. Signed-off-by: Daniel Latypov <dlatypov(a)google.com> --- lib/kunit/test.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/lib/kunit/test.c b/lib/kunit/test.c index 0f66c13d126e..64ee6a9d8003 100644 --- a/lib/kunit/test.c +++ b/lib/kunit/test.c @@ -134,7 +134,7 @@ size_t kunit_suite_num_test_cases(struct kunit_suite *suite) } EXPORT_SYMBOL_GPL(kunit_suite_num_test_cases); -static void kunit_print_subtest_start(struct kunit_suite *suite) +static void kunit_print_suite_start(struct kunit_suite *suite) { kunit_log(KERN_INFO, suite, KUNIT_SUBTEST_INDENT "# Subtest: %s", suite->name); @@ -192,7 +192,7 @@ EXPORT_SYMBOL_GPL(kunit_suite_has_succeeded); static size_t kunit_suite_counter = 1; -static void kunit_print_subtest_end(struct kunit_suite *suite) +static void kunit_print_suite_end(struct kunit_suite *suite) { kunit_print_ok_not_ok((void *)suite, false, kunit_suite_has_succeeded(suite), @@ -498,7 +498,7 @@ int kunit_run_tests(struct kunit_suite *suite) struct kunit_result_stats suite_stats = { 0 }; struct kunit_result_stats total_stats = { 0 }; - kunit_print_subtest_start(suite); + kunit_print_suite_start(suite); kunit_suite_for_each_test_case(suite, test_case) { struct kunit test = { .param_value = NULL, .param_index = 0 }; @@ -552,7 +552,7 @@ int kunit_run_tests(struct kunit_suite *suite) } kunit_print_suite_stats(suite, suite_stats, total_stats); - kunit_print_subtest_end(suite); + kunit_print_suite_end(suite); return 0; } base-commit: 59729170afcd4900e08997a482467ffda8d88c7f -- 2.36.0.rc2.479.g8af0fa9b8e-goog

2 years, 9 months

3
9
0 0

[PATCH] KVM: selftests: Use TAP interface in the kvm_binary_stats_test

by Thomas Huth

The kvm_binary_stats_test test currently does not have any output (unless one of the TEST_ASSERT statement fails), so it's hard to say for a user how far it did proceed already. Thus let's make this a little bit more user-friendly and include some TAP output via the kselftest.h interface. Signed-off-by: Thomas Huth <thuth(a)redhat.com> --- .../testing/selftests/kvm/kvm_binary_stats_test.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/tools/testing/selftests/kvm/kvm_binary_stats_test.c b/tools/testing/selftests/kvm/kvm_binary_stats_test.c index 17f65d514915..aa648834e178 100644 --- a/tools/testing/selftests/kvm/kvm_binary_stats_test.c +++ b/tools/testing/selftests/kvm/kvm_binary_stats_test.c @@ -19,6 +19,7 @@ #include "kvm_util.h" #include "asm/kvm.h" #include "linux/kvm.h" +#include "kselftest.h" static void stats_test(int stats_fd) { @@ -52,7 +53,7 @@ static void stats_test(int stats_fd) /* Sanity check for other fields in header */ if (header->num_desc == 0) { - printf("No KVM stats defined!"); + ksft_print_msg("No KVM stats defined!\n"); return; } /* Check overlap */ @@ -219,12 +220,15 @@ int main(int argc, char *argv[]) max_vcpu = DEFAULT_NUM_VCPU; } + ksft_print_header(); + /* Check the extension for binary stats */ if (kvm_check_cap(KVM_CAP_BINARY_STATS_FD) <= 0) { - print_skip("Binary form statistics interface is not supported"); - exit(KSFT_SKIP); + ksft_exit_skip("Binary form statistics interface is not supported\n"); } + ksft_set_plan(max_vm); + /* Create VMs and VCPUs */ vms = malloc(sizeof(vms[0]) * max_vm); TEST_ASSERT(vms, "Allocate memory for storing VM pointers"); @@ -240,10 +244,12 @@ int main(int argc, char *argv[]) vm_stats_test(vms[i]); for (j = 0; j < max_vcpu; ++j) vcpu_stats_test(vms[i], j); + ksft_test_result_pass("vm%i\n", i); } for (i = 0; i < max_vm; ++i) kvm_vm_free(vms[i]); free(vms); - return 0; + + ksft_finished(); /* Print results and exit() accordingly */ } -- 2.27.0

2 years, 9 months

1
0
0 0

[PATCH v2 0/4] KVM: s390: selftests: Provide TAP output in tests

by Thomas Huth

This patch series is motivated by Shuah's suggestion here: https://lore.kernel.org/kvm/d576d8f7-980f-3bc6-87ad-5a6ae45609b8@linuxfound… Many s390x KVM selftests do not output any information about which tests have been run, so it's hard to say whether a test binary contains a certain sub-test or not. To improve this situation let's add some TAP output via the kselftest.h interface to these tests, so that it easier to understand what has been executed or not. v2: - Reworked the extension checking in the first patch - Make sure to always print the TAP 13 header in the second patch - Reworked the SKIP printing in the third patch Thomas Huth (4): KVM: s390: selftests: Use TAP interface in the memop test KVM: s390: selftests: Use TAP interface in the sync_regs test KVM: s390: selftests: Use TAP interface in the tprot test KVM: s390: selftests: Use TAP interface in the reset test tools/testing/selftests/kvm/s390x/memop.c | 90 +++++++++++++++---- tools/testing/selftests/kvm/s390x/resets.c | 38 ++++++-- .../selftests/kvm/s390x/sync_regs_test.c | 87 +++++++++++++----- tools/testing/selftests/kvm/s390x/tprot.c | 28 ++++-- 4 files changed, 192 insertions(+), 51 deletions(-) -- 2.27.0

2 years, 9 months

3
12
0 0

[PATCH 2/2] selftests/seccomp: Ensure that notifications come in FIFO order

by Sargun Dhillon

When multiple notifications are waiting, ensure they show up in order, as defined by the (predictable) seccomp notification ID. This ensures FIFO ordering of notification delivery as notification ids are monitonic and decided when the notification is generated (as opposed to received). Signed-off-by: Sargun Dhillon <sargun(a)sargun.me> Cc: linux-kselftest(a)vger.kernel.org --- tools/testing/selftests/seccomp/seccomp_bpf.c | 109 ++++++++++++++++++ 1 file changed, 109 insertions(+) diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c b/tools/testing/selftests/seccomp/seccomp_bpf.c index 9d126d7fabdb..33fb3d0c3347 100644 --- a/tools/testing/selftests/seccomp/seccomp_bpf.c +++ b/tools/testing/selftests/seccomp/seccomp_bpf.c @@ -4231,6 +4231,115 @@ TEST(user_notification_addfd_rlimit) close(memfd); } +static char get_proc_stat(int pid) +{ + char proc_path[100] = {0}; + char *line = NULL; + size_t len = 0; + ssize_t nread; + char status; + FILE *f; + int i; + + snprintf(proc_path, sizeof(proc_path), "/proc/%d/stat", pid); + f = fopen(proc_path, "r"); + if (f == NULL) + ksft_exit_fail_msg("%s - Could not open %s\n", + strerror(errno), proc_path); + + for (i = 0; i < 3; i++) { + nread = getdelim(&line, &len, ' ', f); + if (nread <= 0) + ksft_exit_fail_msg("Failed to read status: %s\n", + strerror(errno)); + } + + status = *line; + free(line); + fclose(f); + + return status; +} + +TEST(user_notification_fifo) +{ + struct seccomp_notif_resp resp = {}; + struct seccomp_notif req = {}; + int i, status, listener; + pid_t pid, pids[3]; + __u64 baseid; + long ret; + /* 100 ms */ + struct timespec delay = { .tv_nsec = 100000000 }; + + ret = prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0); + ASSERT_EQ(0, ret) { + TH_LOG("Kernel does not support PR_SET_NO_NEW_PRIVS!"); + } + + /* Setup a listener */ + listener = user_notif_syscall(__NR_getppid, + SECCOMP_FILTER_FLAG_NEW_LISTENER); + ASSERT_GE(listener, 0); + + pid = fork(); + ASSERT_GE(pid, 0); + + if (pid == 0) { + ret = syscall(__NR_getppid); + exit(ret != USER_NOTIF_MAGIC); + } + + EXPECT_EQ(ioctl(listener, SECCOMP_IOCTL_NOTIF_RECV, &req), 0); + baseid = req.id + 1; + + resp.id = req.id; + resp.error = 0; + resp.val = USER_NOTIF_MAGIC; + + /* check that we make sure flags == 0 */ + EXPECT_EQ(ioctl(listener, SECCOMP_IOCTL_NOTIF_SEND, &resp), 0); + + EXPECT_EQ(waitpid(pid, &status, 0), pid); + EXPECT_EQ(true, WIFEXITED(status)); + EXPECT_EQ(0, WEXITSTATUS(status)); + + /* Start children, and them generate notifications */ + for (i = 0; i < ARRAY_SIZE(pids); i++) { + pid = fork(); + if (pid == 0) { + ret = syscall(__NR_getppid); + exit(ret != USER_NOTIF_MAGIC); + } + pids[i] = pid; + } + + /* This spins until all of the children are sleeping */ +restart_wait: + for (i = 0; i < ARRAY_SIZE(pids); i++) { + if (get_proc_stat(pids[i]) != 'S') { + nanosleep(&delay, NULL); + goto restart_wait; + } + } + + /* Read the notifications in order (and respond) */ + for (i = 0; i < ARRAY_SIZE(pids); i++) { + memset(&req, 0, sizeof(req)); + EXPECT_EQ(ioctl(listener, SECCOMP_IOCTL_NOTIF_RECV, &req), 0); + EXPECT_EQ(req.id, baseid + i); + resp.id = req.id; + EXPECT_EQ(ioctl(listener, SECCOMP_IOCTL_NOTIF_SEND, &resp), 0); + } + + /* Make sure notifications were received */ + for (i = 0; i < ARRAY_SIZE(pids); i++) { + EXPECT_EQ(waitpid(pids[i], &status, 0), pids[i]); + EXPECT_EQ(true, WIFEXITED(status)); + EXPECT_EQ(0, WEXITSTATUS(status)); + } +} + /* * TODO: * - expand NNP testing -- 2.25.1

2 years, 9 months

2
3
0 0

[RFC PATCH 0/2] Documentation: dev-tools: begin KTAP spec v2 process

by frowand.list＠gmail.com

From: Frank Rowand <frank.rowand(a)sony.com> An August 2021 RFC patch [1] to create the KTAP Specification resulted in some discussion of possible items to add to the specification. The conversation ended without completing the document. Progress resumed with a December 2021 RFC patch [2] to add a KTAP Specification file (Version 1) to the Linux kernel. Many of the suggestions from the August 2021 discussion were not included in Version 1. This patch series is intended to revisit some of the suggestions from the August 2021 discussion. Patch 1 changes the Specification version to "2-rc" to indicate that following patches are not yet accepted into a final version 2. Patch 2 is an example of a simple change to the Specification. The change does not change the content of the Specification, but updates a formatting directive as suggested by the Documentation maintainer. I intend to take some specific suggestions from the August 2021 discussion to create stand-alone RFC patches to the Specification instead of adding them as additional patches in this series. The intent is to focus discussion on a single area of the Specification in each patch email thread. [1] https://lore.kernel.org/r/CA+GJov6tdjvY9x12JsJT14qn6c7NViJxqaJk+r-K1YJzPggF… [2] https://lore.kernel.org/r/20211207190251.18426-1-davidgow@google.com Frank Rowand (2): Documentation: dev-tools: KTAP spec change version to 2-rc Documentation: dev-tools: use literal block instead of code-block Documentation/dev-tools/ktap.rst | 20 +++++++++----------- 1 file changed, 9 insertions(+), 11 deletions(-) -- Frank Rowand <frank.rowand(a)sony.com>

2 years, 9 months

4
10
0 0

[PATCH v3 0/4] selftests/arm64: Fix O= builds for the FP selftests

by Mark Brown

Currently the arm64 selftests don't support building with O=, this series fixes that, bringing them more into line with how the kselftest Makefiles want to work. v3: - Rebase onto arm64/for-next/core. v2: - Rebase onto v5.18-rc3. Mark Brown (4): selftests/arm64: Use TEST_GEN_PROGS_EXTENDED in the FP Makefile selftests/arm64: Define top_srcdir for the fp tests selftests/arm64: Clean the fp helper libraries selftests/arm64: Fix O= builds for the floating point tests tools/testing/selftests/arm64/fp/Makefile | 49 ++++++++++++----------- 1 file changed, 26 insertions(+), 23 deletions(-) base-commit: 5c346f94d2933ba320af8325cfe77fc58c6e537a -- 2.30.2

2 years, 9 months

2
5
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror