December 2021 - Linux-kselftest-mirror

by Li Zhijian

Hi Folks LKP/0Day found that ww_mutex.sh cannot complete since v5.16-rc1, but I'm pretty sorry that we failed to bisect the FBC, instead, the bisection pointed to a/below merge commit(91e1c99e17) finally. Due to this hang, other tests in the same group are also blocked in 0Day, we hope we can fix this hang ASAP. So if you have any idea about this, or need more debug information, feel free to let me know :) BTW, ww_mutex.sh was failed in v5.15 without hang, and looks it cannot reproduce on a vm. Our box: root@lkp-knm01 ~# lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian Address sizes: 46 bits physical, 48 bits virtual CPU(s): 288 On-line CPU(s) list: 0-287 Thread(s) per core: 4 Core(s) per socket: 72 Socket(s): 1 NUMA node(s): 2 Vendor ID: GenuineIntel CPU family: 6 Model: 133 Model name: Intel(R) Xeon Phi(TM) CPU 7295 @ 1.50GHz Stepping: 0 CPU MHz: 1385.255 CPU max MHz: 1600.0000 CPU min MHz: 1000.0000 BogoMIPS: 2992.76 Virtualization: VT-x L1d cache: 32K L1i cache: 32K L2 cache: 1024K NUMA node0 CPU(s): 0-287 NUMA node1 CPU(s): Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 fma cx16 xtpr pdcm sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch ring3mwait cpuid_fault epb pti tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms avx512f rdseed adx avx512pf avx512er avx512cd xsaveopt dtherm ida arat pln pts avx512_vpopcntdq avx512_4vnniw avx512_4fmaps Below the call stack in v5.16-rc2 [ 1000.374954][ T2713] make: Leaving directory '/usr/src/perf_selftests-x86_64-rhel-8.3-kselftests-136057256686de39cc3a07c2e39ef6bc43003ff6/tools/testing/selftests/locking' [ 1000.375030][ T2713] [ 1000.428791][ T2713] 2021-11-22 22:21:27 make run_tests -C locking [ 1000.428864][ T2713] [ 1000.491043][ T2713] make: Entering directory '/usr/src/perf_selftests-x86_64-rhel-8.3-kselftests-136057256686de39cc3a07c2e39ef6bc43003ff6/tools/testing/selftests/locking' [ 1000.491121][ T2713] [ 1000.540807][ T2713] TAP version 13 [ 1000.540882][ T2713] [ 1000.576050][ T2713] 1..1 [ 1000.576282][ T2713] [ 1000.612980][ T2713] # selftests: locking: ww_mutex.sh [ 1000.613288][ T2713] [ 1495.201324][ T1577] INFO: task kworker/u576:16:1470 blocked for more than 491 seconds. [ 1495.220059][ T1577] Tainted: G B 5.16.0-rc2 #1 [ 1495.240902][ T1577] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1495.265617][ T1577] task:kworker/u576:16 state:D stack: 0 pid: 1470 ppid: 2 flags:0x00004000 [ 1495.289054][ T1577] Workqueue: test-ww_mutex test_cycle_work [test_ww_mutex] [ 1495.310936][ T1577] Call Trace: [ 1495.327809][ T1577] <TASK> [ 1495.344735][ T1577] __schedule+0xdb0/0x25c0 [ 1495.362764][ T1577] ? io_schedule_timeout+0x180/0x180 [ 1495.382013][ T1577] ? lock_downgrade+0x680/0x680 [ 1495.400894][ T1577] ? do_raw_spin_lock+0x125/0x2c0 [ 1495.418866][ T1577] schedule+0xe4/0x280 [ 1495.435597][ T1577] schedule_preempt_disabled+0x18/0x40 [ 1495.454588][ T1577] __ww_mutex_lock+0x1248/0x34c0 [ 1495.476189][ T1577] ? test_cycle_work+0x1bb/0x500 [test_ww_mutex] [ 1495.497763][ T1577] ? mutex_lock_interruptible_nested+0x40/0x40 [ 1495.518959][ T1577] ? lock_downgrade+0x680/0x680 [ 1495.536861][ T1577] ? wait_for_completion_interruptible+0x340/0x340 [ 1495.556253][ T1577] ? ww_mutex_lock+0x3e/0x380 [ 1495.574003][ T1577] ww_mutex_lock+0x3e/0x380 [ 1495.591958][ T1577] test_cycle_work+0x1bb/0x500 [test_ww_mutex] [ 1495.612260][ T1577] ? stress_reorder_work+0xa00/0xa00 [test_ww_mutex] [ 1495.632857][ T1577] ? 0xffffffff81000000 [ 1495.649027][ T1577] ? rcu_read_lock_sched_held+0x5f/0x100 [ 1495.668211][ T1577] ? rcu_read_lock_bh_held+0xc0/0xc0 [ 1495.687010][ T1577] process_one_work+0x817/0x13c0 [ 1495.704991][ T1577] ? rcu_read_unlock+0x40/0x40 [ 1495.723024][ T1577] ? pwq_dec_nr_in_flight+0x280/0x280 [ 1495.740211][ T1577] ? rwlock_bug+0xc0/0xc0 [ 1495.758038][ T1577] worker_thread+0x8b/0xd80 [ 1495.775008][ T1577] ? process_one_work+0x13c0/0x13c0 [ 1495.793017][ T1577] kthread+0x3b9/0x4c0 [ 1495.810782][ T1577] ? set_kthread_struct+0x100/0x100 [ 1495.829988][ T1577] ret_from_fork+0x22/0x30 [ 1495.845811][ T1577] </TASK> [ 1495.859087][ T1577] INFO: task kworker/u576:36:1490 blocked for more than 492 seconds. [ 1495.879048][ T1577] Tainted: G B 5.16.0-rc2 #1 [ 1495.897879][ T1577] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1495.919582][ T1577] task:kworker/u576:36 state:D stack: 0 pid: 1490 ppid: 2 flags:0x00004000 [ 1495.941865][ T1577] Workqueue: test-ww_mutex test_cycle_work [test_ww_mutex] [ 1495.959889][ T1577] Call Trace: [ 1495.974816][ T1577] <TASK> [ 1495.988759][ T1577] __schedule+0xdb0/0x25c0 [ 1495.988759][ T1577] __schedule+0xdb0/0x25c0 [ 1496.003849][ T1577] ? io_schedule_timeout+0x180/0x180 [ 1496.020839][ T1577] ? lock_downgrade+0x680/0x680 [ 1496.036854][ T1577] ? do_raw_spin_lock+0x125/0x2c0 [ 1496.051976][ T1577] schedule+0xe4/0x280 [ 1496.067780][ T1577] schedule_preempt_disabled+0x18/0x40 [ 1496.085004][ T1577] __ww_mutex_lock+0x1248/0x34c0 [ 1496.101895][ T1577] ? test_cycle_work+0x1bb/0x500 [test_ww_mutex] [ 1496.119889][ T1577] ? mutex_lock_interruptible_nested+0x40/0x40 [ 1496.137873][ T1577] ? lock_downgrade+0x680/0x680 [ 1496.152657][ T1577] ? wait_for_completion_interruptible+0x340/0x340 [ 1496.168773][ T1577] ? ww_mutex_lock+0x3e/0x380 [ 1496.184862][ T1577] ww_mutex_lock+0x3e/0x380 [ 1496.199979][ T1577] test_cycle_work+0x1bb/0x500 [test_ww_mutex] [ 1496.216277][ T1577] ? stress_reorder_work+0xa00/0xa00 [test_ww_mutex] [ 1496.234904][ T1577] ? 0xffffffff81000000 [ 1496.249856][ T1577] ? rcu_read_lock_sched_held+0x5f/0x100 [ 1496.265951][ T1577] ? rcu_read_lock_bh_held+0xc0/0xc0 [ 1496.282815][ T1577] process_one_work+0x817/0x13c0 [ 1496.299791][ T1577] ? rcu_read_unlock+0x40/0x40 [ 1496.314754][ T1577] ? pwq_dec_nr_in_flight+0x280/0x280 [ 1496.331779][ T1577] ? rwlock_bug+0xc0/0xc0 [ 1496.348007][ T1577] worker_thread+0x8b/0xd80 [ 1496.362905][ T1577] ? process_one_work+0x13c0/0x13c0 [ 1496.378975][ T1577] kthread+0x3b9/0x4c0 [ 1496.393866][ T1577] ? set_kthread_struct+0x100/0x100 [ 1496.408827][ T1577] ret_from_fork+0x22/0x30 [ 1496.423901][ T1577] </TASK> [ 1496.437994][ T1577] INFO: task kworker/u576:0:15113 blocked for more than 492 seconds. [ 1496.455862][ T1577] Tainted: G B 5.16.0-rc2 #1 [ 1496.473759][ T1577] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1496.494808][ T1577] task:kworker/u576:0 state:D stack: 0 pid:15113 ppid: 2 flags:0x00004000 [ 1496.517000][ T1577] Workqueue: test-ww_mutex test_cycle_work [test_ww_mutex] [ 1496.537035][ T1577] Call Trace: [ 1496.551187][ T1577] <TASK> [ 1496.566405][ T1577] __schedule+0xdb0/0x25c0 [ 1496.582012][ T1577] ? io_schedule_timeout+0x180/0x180 [ 1496.598049][ T1577] ? lock_downgrade+0x680/0x680 [ 1496.615360][ T1577] ? do_raw_spin_lock+0x125/0x2c0 [ 1496.631835][ T1577] schedule+0xe4/0x280 [ 1496.645972][ T1577] schedule_preempt_disabled+0x18/0x40 [ 1496.663774][ T1577] __ww_mutex_lock+0x1248/0x34c0 [ 1496.681795][ T1577] ? test_cycle_work+0x1bb/0x500 [test_ww_mutex] [ 1496.698731][ T1577] ? mutex_lock_interruptible_nested+0x40/0x40 [ 1496.714996][ T1577] ? lock_downgrade+0x680/0x680 [ 1496.730888][ T1577] ? wait_for_completion_interruptible+0x340/0x340 [ 1496.747926][ T1577] ? ww_mutex_lock+0x3e/0x380 [ 1496.762482][ T1577] ww_mutex_lock+0x3e/0x380 [ 1496.778844][ T1577] test_cycle_work+0x1bb/0x500 [test_ww_mutex] And, we found that it occasionally hangs on v5.16-rc3 (1/3 runs), below is a good dmesg. [ 962.136756][ T2950] make: Entering directory '/usr/src/perf_selftests-x86_64-rhel-8.3-kselftests-d58071a8a76d779eedab38033ae4c821c30295a5/tools/testing/selftests/locking' [ 962.136831][ T2950]- [ 962.205036][ T2950] TAP version 13 [ 962.206003][ T2950]- [ 962.298458][ T2950] 1..1 [ 962.299657][ T2950]- [ 962.345588][ T2950] # selftests: locking: ww_mutex.sh [ 962.345657][ T2950]- [ 973.641869][T25509] All ww mutex selftests passed [ 973.773996][ T2950] # locking/ww_mutex: ok [ 973.774068][ T2950]- [ 973.774236][ T2960] # locking/ww_mutex: ok [ 973.802355][ T2960]- [ 973.829966][ T2950] ok 1 selftests: locking: ww_mutex.sh [ 973.834748][ T2950]- [ 973.838302][ T2960] ok 1 selftests: locking: ww_mutex.sh [ 973.899815][ T2960]- [ 973.921431][ T2950] make: Leaving directory '/usr/src/perf_selftests-x86_64-rhel-8.3-kselftests-d58071a8a76d779eedab38033ae4c821c30295a5/tools/testing/selftests/locking' [ 973.932312][ T2950]- [ 973.957345][ T2960] make: Leaving directory '/usr/src/perf_selftests-x86_64-rhel-8.3-kselftests-d58071a8a76d779eedab38033ae4c821c30295a5/tools/testing/selftests/locking' Thanks Zhijian@0Day

9 months, 3 weeks

3
3
0 0

[PATCH v2] selftests/kselftest/runner/run_one(): Allow running non-executable files

by SeongJae Park

From: SeongJae Park <sjpark(a)amazon.de> When running a test program, 'run_one()' checks if the program has the execution permission and fails if it doesn't. However, it's easy to mistakenly missing the permission, as some common tools like 'diff' don't support the permission change well[1]. Compared to that, making mistakes in the test program's path would only rare, as those are explicitly listed in 'TEST_PROGS'. Therefore, it might make more sense to resolve the situation on our own and run the program. For the reason, this commit makes the test program runner function to still print the warning message but try parsing the interpreter of the program and explicitly run it with the interpreter, in the case. [1] https://lore.kernel.org/mm-commits/YRJisBs9AunccCD4@kroah.com/ Suggested-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: SeongJae Park <sjpark(a)amazon.de> --- Changes from v1 (https://lore.kernel.org/linux-kselftest/20210810140459.23990-1-sj38.park@gm…) - Parse and use the interpreter instead of changing the file tools/testing/selftests/kselftest/runner.sh | 28 +++++++++++++-------- 1 file changed, 18 insertions(+), 10 deletions(-) diff --git a/tools/testing/selftests/kselftest/runner.sh b/tools/testing/selftests/kselftest/runner.sh index cc9c846585f0..a9ba782d8ca0 100644 --- a/tools/testing/selftests/kselftest/runner.sh +++ b/tools/testing/selftests/kselftest/runner.sh @@ -33,9 +33,9 @@ tap_timeout() { # Make sure tests will time out if utility is available. if [ -x /usr/bin/timeout ] ; then - /usr/bin/timeout --foreground "$kselftest_timeout" "$1" + /usr/bin/timeout --foreground "$kselftest_timeout" $1 else - "$1" + $1 fi } @@ -65,17 +65,25 @@ run_one() TEST_HDR_MSG="selftests: $DIR: $BASENAME_TEST" echo "# $TEST_HDR_MSG" - if [ ! -x "$TEST" ]; then - echo -n "# Warning: file $TEST is " - if [ ! -e "$TEST" ]; then - echo "missing!" - else - echo "not executable, correct this." - fi + if [ ! -e "$TEST" ]; then + echo "# Warning: file $TEST is missing!" echo "not ok $test_num $TEST_HDR_MSG" else + cmd="./$BASENAME_TEST" + if [ ! -x "$TEST" ]; then + echo "# Warning: file $TEST is not executable" + + if [ $(head -n 1 "$TEST" | cut -c -2) = "#!" ] + then + interpreter=$(head -n 1 "$TEST" | cut -c 3-) + cmd="$interpreter ./$BASENAME_TEST" + else + echo "not ok $test_num $TEST_HDR_MSG" + return + fi + fi cd `dirname $TEST` > /dev/null - ((((( tap_timeout ./$BASENAME_TEST 2>&1; echo $? >&3) | + ((((( tap_timeout "$cmd" 2>&1; echo $? >&3) | tap_prefix >&4) 3>&1) | (read xs; exit $xs)) 4>>"$logfile" && echo "ok $test_num $TEST_HDR_MSG") || -- 2.17.1

1 year

3
6
0 0

[PATCH net-next v2 0/3] net: introduce rps_default_mask

by Paolo Abeni

Real-time setups try hard to ensure proper isolation between time critical applications and e.g. network processing performed by the network stack in softirq and RPS is used to move the softirq activity away from the isolated core. If the network configuration is dynamic, with netns and devices routinely created at run-time, enforcing the correct RPS setting on each newly created device allowing to transient bad configuration became complex. These series try to address the above, introducing a new sysctl knob: rps_default_mask. The new sysctl entry allows configuring a systemwide RPS mask, to be enforced since receive queue creation time without any fourther per device configuration required. Additionally, a simple self-test is introduced to check the rps_default_mask behavior. v1 -> v2: - fix sparse warning in patch 2/3 Paolo Abeni (3): net/sysctl: factor-out netdev_rx_queue_set_rps_mask() helper net/core: introduce default_rps_mask netns attribute self-tests: introduce self-tests for RPS default mask Documentation/admin-guide/sysctl/net.rst | 6 ++ include/linux/netdevice.h | 1 + net/core/net-sysfs.c | 73 +++++++++++-------- net/core/sysctl_net_core.c | 58 +++++++++++++++ tools/testing/selftests/net/Makefile | 1 + tools/testing/selftests/net/config | 3 + .../testing/selftests/net/rps_default_mask.sh | 57 +++++++++++++++ 7 files changed, 169 insertions(+), 30 deletions(-) create mode 100755 tools/testing/selftests/net/rps_default_mask.sh -- 2.26.2

1 year, 2 months

4
12
0 0

[PATCH v2 net-next 0/3] ptp: Add adjust phase to support phase offset.

by vincent.cheng.xh＠renesas.com

From: Vincent Cheng <vincent.cheng.xh(a)renesas.com> This series adds adjust phase to the PTP Hardware Clock device interface. Some PTP hardware clocks have a write phase mode that has a built-in hardware filtering capability. The write phase mode utilizes a phase offset control word instead of a frequency offset control word. Add adjust phase function to take advantage of this capability. Changes since v1: - As suggested by Richard Cochran: 1. ops->adjphase is new so need to check for non-null function pointer. 2. Kernel coding style uses lower_case_underscores. 3. Use existing PTP clock API for delayed worker. Vincent Cheng (3): ptp: Add adjphase function to support phase offset control. ptp: Add adjust_phase to ptp_clock_caps capability. ptp: ptp_clockmatrix: Add adjphase() to support PHC write phase mode. drivers/ptp/ptp_chardev.c | 1 + drivers/ptp/ptp_clock.c | 3 ++ drivers/ptp/ptp_clockmatrix.c | 92 +++++++++++++++++++++++++++++++++++ drivers/ptp/ptp_clockmatrix.h | 8 ++- include/linux/ptp_clock_kernel.h | 6 ++- include/uapi/linux/ptp_clock.h | 4 +- tools/testing/selftests/ptp/testptp.c | 6 ++- 7 files changed, 114 insertions(+), 6 deletions(-) -- 2.7.4

1 year, 8 months

5
8
0 0

[PATCH] selftests/ftrace: func_event_triggers: fix typo in user message

by Randy Dunlap

Correct typo of "it's" to "it". Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org> Cc: Steven Rostedt <rostedt(a)goodmis.org> Cc: Ingo Molnar <mingo(a)redhat.com> Cc: Shuah Khan <shuah(a)kernel.org> Cc: linux-kselftest(a)vger.kernel.org --- tools/testing/selftests/ftrace/test.d/ftrace/func_event_triggers.tc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20211224.orig/tools/testing/selftests/ftrace/test.d/ftrace/func_event_triggers.tc +++ linux-next-20211224/tools/testing/selftests/ftrace/test.d/ftrace/func_event_triggers.tc @@ -85,7 +85,7 @@ run_enable_disable() { echo $check_disable > $EVENT_ENABLE done sleep $SLEEP_TIME - echo " make sure it's still works" + echo " make sure it still works" test_event_enabled $check_enable_star reset_ftrace_filter

1 year, 9 months

2
2
0 0

Re: [PATCH 2/2] kvm: rename KVM_MAX_VCPU_ID to, KVM_MAX_VCPU_IDS

by Christian Zigotzky

Hello Juergen, Hello All, Since the RC1 of kernel 5.13, -smp 2 and -smp 4 don't work with a virtual e5500 QEMU KVM-HV machine anymore. [1] I see in the serial console, that the uImage doesn't load. I use the following QEMU command for booting: qemu-system-ppc64 -M ppce500 -cpu e5500 -enable-kvm -m 1024 -kernel uImage -drive format=raw,file=MintPPC32-X5000.img,index=0,if=virtio -netdev user,id=mynet0 -device virtio-net,netdev=mynet0 -append "rw root=/dev/vda" -device virtio-vga -device virtio-mouse-pci -device virtio-keyboard-pci -device pci-ohci,id=newusb -device usb-audio,bus=newusb.0 -smp 4 The kernels boot without KVM-HV. Summary for KVM-HV: -smp 1 -> works -smp 2 -> doesn't work -smp 3 -> works -smp 4 -> doesn't work I used -smp 4 before the RC1 of kernel 5.13 because my FSL P5040 BookE machine [2] has 4 cores. Does this patch solve this issue? [3] Thanks, Christian [1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-May/229103.html [2] http://wiki.amiga.org/index.php?title=X5000 [3] https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-September/234152.html

1 year, 9 months

1
1
0 0

[PATCH v9 0/6] test_sysfs: add new selftest for sysfs

by Luis Chamberlain

On this v9 I've dropped the generic sysfs deadlock fix given Ming Lei has provided alternative fixes for the zram driver without incurring a generic lock *and* we don't yet have full assessment of how wide spread the deadlock case might be in the kernel. A full assessment effort is still underway using Coccinelle with iteration support, however that effort will take a bit more time to complete. We can re-evaluate the value of a generic fix later after the assessment is complete. This series now just adds the test_sysfs selftest and failure injection support for it on kernfs. The most valuable tests are those which confirm that once a kernfs active reference is obtained with kernfs_get_active() the pointers used there are still valid, and so using sysfs ops *are* safe if we race against module removal. Likewise it also confirms how module removal will *wait* for these ops to complete if a kernfs node is already active. This v9 series also addresses feedback mostly provided by Kees Cook and Greg. I also made a few changes to the test_sysfs driver to account for changes in the block layer. I also improved the kernfs failure injection tests with documentation of how they work and to account for the real expected return value of a write before the kernfs active reference is obtained. Upstream commit 8e141f9eb803e ("block: drain file system I/O on del_gendisk") has revealed that small minor induced delays on del_gendisk() can make a few writes succeed if the delays used are small. So we clarify the logic of why writes could either fail or succeed before the kernfs active reference is taken. These changes also availble on this tree: https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux-next.git/log/?… v9: * rebased onto linux-next tag next-20211029 * add Reviewed-by tags for the SPDX change, and the drivers which get the tag for it * drop the generic sysfs deadlock fix for now as the scope of how wide spread the issue is still needs to be assessed * drop the zram patches as they are replaced by Ming Lei's fixes * drop already merged patches * try_module_get() docs: enhanced using feedback from Kees Cook. I extended the documention to make it clear that if proper care is not taken the use of this routine could crash the kernel. * kernfs: move failure injection knobs under /sys/kernel/debug/fail_kernfs as suggested by Kees Cook * kernfs: rename failure injection file to fault_inject.c as suggested by Kees Cook * kernfs: split up documentation of failure injection knobs as suggested by Kees Cook * kernfs: move the wait into debug call, and use a simple one liner may_wait() calls to make the changes much less intrusive and more readable as suggested by Kees Cook * kernfs: drop __func__ uses as suggested by Kees Cook * test_sysfs: use sizeof() instead of open coded 16 as suggested by Kees Cook * test_sysfs: use sysfs_emit as suggested by Kees Cook * test_sysfs: drop boiler place license as suggested by Greg KH * test_sysfs: use depends instead of select as suggested by Kees Cook * test_sysfs: drop #ifdefery as suggested by Kees Cook * test_sysfs: clarified that the use of a lock on rmmod which causes a deadlock is something drivers should avoid, and its why we leave the test disabled. * test_sysfs: now that device_add_disk() returns an error, use the new error return code, otherwise this is going to prevent us from eventually embracing __must_check() on that call on the block layer. * test_syfs: testdev_submit_bio() needed to change data types as now it returns void. * test_sysfs: enhance kernfs failure injection tests with documenation and correct the expected return value for writes Luis Chamberlain (6): LICENSES: Add the copyleft-next-0.3.1 license testing: use the copyleft-next-0.3.1 SPDX tag selftests: add tests_sysfs module kernfs: add initial failure injection support test_sysfs: add support to use kernfs failure injection kernel/module: add documentation for try_module_get() .../fault-injection/fault-injection.rst | 50 + LICENSES/dual/copyleft-next-0.3.1 | 237 +++ MAINTAINERS | 9 +- fs/kernfs/Makefile | 1 + fs/kernfs/fault_inject.c | 93 ++ fs/kernfs/file.c | 9 + fs/kernfs/kernfs-internal.h | 70 + include/linux/kernfs.h | 5 + include/linux/module.h | 37 +- lib/Kconfig.debug | 23 + lib/Makefile | 1 + lib/test_kmod.c | 12 +- lib/test_sysctl.c | 12 +- lib/test_sysfs.c | 913 +++++++++++ tools/testing/selftests/kmod/kmod.sh | 13 +- tools/testing/selftests/sysctl/sysctl.sh | 12 +- tools/testing/selftests/sysfs/Makefile | 12 + tools/testing/selftests/sysfs/config | 5 + tools/testing/selftests/sysfs/settings | 1 + tools/testing/selftests/sysfs/sysfs.sh | 1411 +++++++++++++++++ 20 files changed, 2878 insertions(+), 48 deletions(-) create mode 100644 LICENSES/dual/copyleft-next-0.3.1 create mode 100644 fs/kernfs/fault_inject.c create mode 100644 lib/test_sysfs.c create mode 100644 tools/testing/selftests/sysfs/Makefile create mode 100644 tools/testing/selftests/sysfs/config create mode 100644 tools/testing/selftests/sysfs/settings create mode 100755 tools/testing/selftests/sysfs/sysfs.sh -- 2.30.2

1 year, 10 months

9
35
0 0

[PATCH v3 0/6] KVM: my debug patch queue

by Maxim Levitsky

Hi! I would like to publish two debug features which were needed for other stuff I work on. One is the reworked lx-symbols script which now actually works on at least gdb 9.1 (gdb 9.2 was reported to fail to load the debug symbols from the kernel for some reason, not related to this patch) and upstream qemu. The other feature is the ability to trap all guest exceptions (on SVM for now) and see them in kvmtrace prior to potential merge to double/triple fault. This can be very useful and I already had to manually patch KVM a few times for this. I will, once time permits, implement this feature on Intel as well. V2: * Some more refactoring and workarounds for lx-symbols script * added KVM_GUESTDBG_BLOCKIRQ flag to enable 'block interrupts on single step' together with KVM_CAP_SET_GUEST_DEBUG2 capability to indicate which guest debug flags are supported. This is a replacement for unconditional block of interrupts on single step that was done in previous version of this patch set. Patches to qemu to use that feature will be sent soon. * Reworked the the 'intercept all exceptions for debug' feature according to the review feedback: - renamed the parameter that enables the feature and moved it to common kvm module. (only SVM part is currently implemented though) - disable the feature for SEV guests as was suggested during the review - made the vmexit table const again, as was suggested in the review as well. V3: * Modified a selftest to cover the KVM_GUESTDBG_BLOCKIRQ * Rebased on kvm/queue Best regards, Maxim Levitsky Maxim Levitsky (6): KVM: SVM: split svm_handle_invalid_exit KVM: x86: add force_intercept_exceptions_mask KVM: SVM: implement force_intercept_exceptions_mask scripts/gdb: rework lx-symbols gdb script KVM: x86: implement KVM_GUESTDBG_BLOCKIRQ KVM: selftests: test KVM_GUESTDBG_BLOCKIRQ Documentation/virt/kvm/api.rst | 1 + arch/x86/include/asm/kvm_host.h | 5 +- arch/x86/include/uapi/asm/kvm.h | 1 + arch/x86/kvm/svm/svm.c | 87 +++++++- arch/x86/kvm/svm/svm.h | 6 +- arch/x86/kvm/x86.c | 12 +- arch/x86/kvm/x86.h | 2 + kernel/module.c | 8 +- scripts/gdb/linux/symbols.py | 203 ++++++++++++------ .../testing/selftests/kvm/x86_64/debug_regs.c | 24 ++- 10 files changed, 266 insertions(+), 83 deletions(-) -- 2.26.3

2 years, 1 month

4
27
0 0

[PATCH v2] selftests/resctrl: Print a message if the result of MBM&CMT tests is failed when Intel Sub-NUMA is enabled

by Shaopeng Tan

If the result of MBM&CMT tests is failed when Intel Sub-NUMA is enabled, print a possible causes of failure. Since when the Intel Sub-NUMA Clustering(SNC) feature is enabled, the CMT and MBM counters may not be accurate. Signed-off-by: Shaopeng Tan <tan.shaopeng(a)jp.fujitsu.com> --- Hello, According to the Intel RDT reference Manual, when the sub-numa clustering feature is enabled, the CMT and MBM counters may not be accurate. When running CMT tests and MBM tests on 2nd Generation Intel Xeon Scalable Processor, the result may be "not ok". If result of MBM&CMT tests is failed when Intel Sub-NUMA is enabled, fix it to print a possible cause of failure, instead of SKIP these tests in v1. Thanks, tools/testing/selftests/resctrl/Makefile | 1 + tools/testing/selftests/resctrl/cmt_test.c | 5 ++- tools/testing/selftests/resctrl/mbm_test.c | 5 ++- tools/testing/selftests/resctrl/resctrl.h | 2 ++ .../testing/selftests/resctrl/resctrl_tests.c | 36 +++++++++++++++++++ tools/testing/selftests/resctrl/resctrlfs.c | 26 ++++++++++++++ 6 files changed, 73 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/resctrl/Makefile b/tools/testing/selftests/resctrl/Makefile index adfd92145e12..6d257f40e6ac 100644 --- a/tools/testing/selftests/resctrl/Makefile +++ b/tools/testing/selftests/resctrl/Makefile @@ -1,6 +1,7 @@ #SPDX-License-Identifier: GPL-2.0 CFLAGS += -g -Wall -O2 -D_FORTIFY_SOURCE=2 +LDLIBS += -lnuma TEST_GEN_PROGS := resctrl_tests EXTRA_SOURCES := $(wildcard *.c) diff --git a/tools/testing/selftests/resctrl/cmt_test.c b/tools/testing/selftests/resctrl/cmt_test.c index 8968e36db99d..c5a49444c5a0 100644 --- a/tools/testing/selftests/resctrl/cmt_test.c +++ b/tools/testing/selftests/resctrl/cmt_test.c @@ -136,8 +136,11 @@ int cmt_resctrl_val(int cpu_no, int n, char **benchmark_cmd) return ret; ret = check_results(&param, n); - if (ret) + if (ret) { + if (sub_numa_cluster_enable) + ksft_print_msg("Sub-NUMA Clustering(SNC) feature is enabled, the CMT counters may not be accurate.\n"); return ret; + } cmt_test_cleanup(); diff --git a/tools/testing/selftests/resctrl/mbm_test.c b/tools/testing/selftests/resctrl/mbm_test.c index 8392e5c55ed0..7dc1bdf2d0b8 100644 --- a/tools/testing/selftests/resctrl/mbm_test.c +++ b/tools/testing/selftests/resctrl/mbm_test.c @@ -136,8 +136,11 @@ int mbm_bw_change(int span, int cpu_no, char *bw_report, char **benchmark_cmd) return ret; ret = check_results(span); - if (ret) + if (ret) { + if (sub_numa_cluster_enable) + ksft_print_msg("Sub-NUMA Clustering(SNC) feature is enabled, the MBM counters may not be accurate.\n"); return ret; + } mbm_test_cleanup(); diff --git a/tools/testing/selftests/resctrl/resctrl.h b/tools/testing/selftests/resctrl/resctrl.h index 1ad10c47e31d..4b8ad4fbd016 100644 --- a/tools/testing/selftests/resctrl/resctrl.h +++ b/tools/testing/selftests/resctrl/resctrl.h @@ -76,6 +76,7 @@ extern pid_t bm_pid, ppid; extern char llc_occup_path[1024]; extern bool is_amd; +extern bool sub_numa_cluster_enable; bool check_resctrlfs_support(void); int filter_dmesg(void); @@ -85,6 +86,7 @@ int umount_resctrlfs(void); int validate_bw_report_request(char *bw_report); bool validate_resctrl_feature_request(const char *resctrl_val); char *fgrep(FILE *inf, const char *str); +char *fgrep_last_match_line(FILE *inf, const char *str); int taskset_benchmark(pid_t bm_pid, int cpu_no); void run_benchmark(int signum, siginfo_t *info, void *ucontext); int write_schemata(char *ctrlgrp, char *schemata, int cpu_no, diff --git a/tools/testing/selftests/resctrl/resctrl_tests.c b/tools/testing/selftests/resctrl/resctrl_tests.c index 3be0895c492b..bbab4a7f37ed 100644 --- a/tools/testing/selftests/resctrl/resctrl_tests.c +++ b/tools/testing/selftests/resctrl/resctrl_tests.c @@ -8,12 +8,15 @@ * Sai Praneeth Prakhya <sai.praneeth.prakhya(a)intel.com>, * Fenghua Yu <fenghua.yu(a)intel.com> */ +#include <numa.h> +#include <string.h> #include "resctrl.h" #define BENCHMARK_ARGS 64 #define BENCHMARK_ARG_SIZE 64 bool is_amd; +bool sub_numa_cluster_enable; void detect_amd(void) { @@ -34,6 +37,35 @@ void detect_amd(void) fclose(inf); } +void check_sub_numa_cluster(void) +{ + FILE *inf = fopen("/proc/cpuinfo", "r"); + char *res, *s; + int socket_num = 0; + int numa_nodes = 0; + + if (!inf) + return; + + res = fgrep_last_match_line(inf, "physical id"); + + if (res) { + s = strpbrk(res, "1234567890"); + socket_num = atoi(s) + 1; + free(res); + } + fclose(inf); + + numa_nodes = numa_max_node() + 1; + + /* + * when the Sub-NUMA Clustering(SNC) feature is enabled, + * the number of numa nodes is twice the number of sockets. + */ + if (numa_nodes == (2 * socket_num)) + sub_numa_cluster_enable = true; +} + static void cmd_help(void) { printf("usage: resctrl_tests [-h] [-b \"benchmark_cmd [options]\"] [-t test list] [-n no_of_bits]\n"); @@ -210,6 +242,10 @@ int main(int argc, char **argv) /* Detect AMD vendor */ detect_amd(); + /* check whether sub numa clustering is enable or not */ + if (!is_amd) + check_sub_numa_cluster(); + if (has_ben) { /* Extract benchmark command from command line. */ for (i = ben_ind; i < argc; i++) { diff --git a/tools/testing/selftests/resctrl/resctrlfs.c b/tools/testing/selftests/resctrl/resctrlfs.c index 5f5a166ade60..1908ecb14b70 100644 --- a/tools/testing/selftests/resctrl/resctrlfs.c +++ b/tools/testing/selftests/resctrl/resctrlfs.c @@ -605,6 +605,32 @@ char *fgrep(FILE *inf, const char *str) return NULL; } +/* + * Find the last matched line. + * Return a pointer to the string of the matched line, + * else retuen NULL if no matched line + */ +char *fgrep_last_match_line(FILE *inf, const char *str) +{ + char line[256]; + char result_line[256]; + int slen = strlen(str); + + while (!feof(inf)) { + if (!fgets(line, 256, inf)) + break; + if (strncmp(line, str, slen)) + continue; + + strcpy(result_line, line); + } + + if (strlen(result_line) >= slen) + return strdup(result_line); + + return NULL; +} + /* * validate_resctrl_feature_request - Check if requested feature is valid. * @resctrl_val: Requested feature -- 2.27.0

2 years, 2 months

3
5
0 0

RFC - kernel test result specification (KTAP)

by Rae Moar

We are looking to further standardise the output format used by kernel test frameworks like kselftest and KUnit. Thus far we have used the TAP (Test Anything Protocol) specification, but it has been extended in many different ways, so we would like to agree on a common "Kernel TAP" (KTAP) format to resolve these differences. Thus, below is a draft of a specification of KTAP. Note that this specification is largely based on the current format of test results for KUnit tests. Additionally, this specification was heavily inspired by the KTAP specification draft by Tim Bird (https://lore.kernel.org/linux-kselftest/CY4PR13MB1175B804E31E502221BC8163FD…). However, there are some notable differences to his specification. One such difference is the format of nested tests is more fully specified in the following specification. However, they are specified in a way which may not be compatible with many kselftest nested tests. ===================== Specification of KTAP ===================== TAP, or the Test Anything Protocol is a format for specifying test results used by a number of projects. It's website and specification are found at: https://testanything.org/. The Linux Kernel uses TAP output for test results. However, KUnit (and other Kernel testing frameworks such as kselftest) have some special needs for test results which don't gel perfectly with the original TAP specification. Thus, a "Kernel TAP" (KTAP) format is specified to extend and alter TAP to support these use-cases. KTAP Output consists of 5 major elements (all line-based): - The version line - Plan lines - Test case result lines - Diagnostic lines - A bail out line An important component in this specification of KTAP is the specification of the format of nested tests. This can be found in the section on nested tests below. The version line ---------------- The first line of KTAP output must be the version line. As this specification documents the first version of KTAP, the recommended version line is "KTAP version 1". However, since all kernel testing frameworks use TAP version lines, "TAP version 14" and "TAP version 13" are all acceptable version lines. Version lines with other versions of TAP or KTAP will not cause the parsing of the test results to fail but it will produce an error. Plan lines ---------- Plan lines must follow the format of "1..N" where N is the number of subtests. The second line of KTAP output must be a plan line, which indicates the number of tests at the highest level, such that the tests do not have a parent. Also, in the instance of a test having subtests, the second line of the test after the subtest header must be a plan line which indicates the number of subtests within that test. Test case result lines ---------------------- Test case result lines must have the format: <result> <number> [-] [<description>] [<directive>] [<diagnostic data>] The result can be either "ok", which indicates the test case passed, or "not ok", which indicates that the test case failed. The number represents the number of the test case or suite being performed. The first test case or suite must have the number 1 and the number must increase by 1 for each additional test case or result at the same level and within the same testing suite. The "-" character is optional. The description is a description of the test, generally the name of the test, and can be any string of words (can't include #). The description is optional. The directive is used to indicate if a test was skipped. The format for the directive is: "# SKIP [<skip_description>]". The skip_description is optional and can be any string of words to describe why the test was skipped. The result of the test case result line can be either "ok" or "not ok" if the skip directive is used. Finally, note that TAP 14 specification includes TODO directives but these are not supported for KTAP. Examples of test case result lines: Test passed: ok 1 - test_case_name Test was skipped: not ok 1 - test_case_name # SKIP test_case_name should be skipped Test failed: not_ok 1 - test_case_name Diagnostic lines ---------------- Diagnostic lines are used for description of testing operations. Diagnostic lines are generally formatted as "# <diagnostic_description>", where the description can be any string. However, in practice, diagnostic lines are all lines that don't follow the format of any other KTAP line format. Diagnostic lines can be anywhere in the test output after the first two lines. There are a few special diagnostic lines. Diagnostic lines of the format "# Subtest: <test_name>" indicate the start of a test with subtests. Also, diagnostic lines of the format "# <test_name>: <description>" refer to a specific test and tend to occur before the test result line of that test but are optional. Bail out line ------------- A bail out line can occur anywhere in the KTAP output and will indicate that a test has crashed. The format of a bail out line is "Bail out! [<description>]", where the description can give information on why the bail out occurred and can be any string. Nested tests ------------ The new specification for KTAP will support an arbitrary number of nested subtests. Thus, tests can now have subtests and those subtests can have subtests. This can be useful to further categorize tests and organize test results. The new required format for a test with subtests consists of: a subtest header line, a plan line, all subtests, and a final test result line. The first line of the test must be the subtest header line with the format: "# Subtest: <test_name>". The second line of the test must be the plan line, which is formatted as "1..N", where N is the number of subtests. Following the plan line, all lines pertaining to the subtests will follow. Finally, the last line of the test is a final test result line with the format: "(ok|not ok) <number> [-] [<description>] [<directive>] [<diagnostic data>]", which follows the same format as the general test result lines described in this section. The result line should indicate the result of the subtests. Thus, if one of the subtests fail, the test should fail. The description in the final test result line should match the name of the test in the subtest header. An example format: KTAP version 1 1..1 # Subtest: test_suite 1..2 ok 1 - test_1 ok 2 - test_2 ok 1 - test_suite An example format with multiple levels of nested testing: KTAP version 1 1..1 # Subtest: test_suite 1..2 # Subtest: sub_test_suite 1..2 ok 1 - test_1 ok 2 test_2 ok 1 - sub_test_suite ok 2 - test ok 1 - test_suite In the instance that the plan line is missing, the end of the test will be denoted by the final result line containing a description that matches the name of the test given in the subtest header. Note that thus, if the plan line is missing and one of the subtests have a matching name to the test suite this will cause errors. Lastly, indentation is also recommended for improved readability. Major differences between TAP 14 and KTAP specification ------------------------------------------------------- Note that the major differences between TAP 14 and KTAP specification: - yaml and json are not allowed in diagnostic messages - TODO directive not allowed - KTAP allows for an arbitrary number of tests to be nested with specified nested test format Example of KTAP --------------- KTAP version 1 1..1 # Subtest: test_suite 1..1 # Subtest: sub_test_suite 1..2 ok 1 - test_1 ok 2 test_2 ok 1 - sub_test_suite ok 1 - test_suite ========================================= Note on incompatibilities with kselftests ========================================= To my knowledge, the above specification seems to generally accept the TAP format of many non-nested test results of kselftests. An example of a common kselftests TAP format for non-nested test results that are accepted by the above specification: TAP version 13 1..2 # selftests: vDSO: vdso_test_gettimeofday # The time is 1628024856.096879 ok 1 selftests: vDSO: vdso_test_gettimeofday # selftests: vDSO: vdso_test_getcpu # Could not find __vdso_getcpu ok 2 selftests: vDSO: vdso_test_getcpu # SKIP However, one major difference noted with kselftests is the use of more directives than the "# SKIP" directive. kselftest also supports XPASS and XFAIL directives. Some additional examples found in kselftests: not ok 5 selftests: netfilter: nft_concat_range.sh # TIMEOUT 45 seconds not ok 45 selftests: kvm: kvm_binary_stats_test # exit=127 Should the specification be expanded to include these directives? However, the general format for kselftests with nested test results seems to differ from the above specification. It seems that a general format for nested tests is as follows: TAP version 13 1..2 # selftests: membarrier: membarrier_test_single_thread # TAP version 13 # 1..2 # ok 1 sys_membarrier available # ok 2 sys membarrier invalid command test: command = -1, flags = 0, errno = 22. Failed as expected ok 1 selftests: membarrier: membarrier_test_single_thread # selftests: membarrier: membarrier_test_multi_thread # TAP version 13 # 1..2 # ok 1 sys_membarrier available # ok 2 sys membarrier invalid command test: command = -1, flags = 0, errno = 22. Failed as expected ok 2 selftests: membarrier: membarrier_test_multi_thread The major differences here, that do not match the above specification, are use of "# " as an indentation and using a TAP version line to denote a new test with subtests rather than the subtest header line described above. If these are widely utilized formats in kselftests, should we include both versions in the specification or should we attempt to agree on a single format for nested tests? I personally believe we should try to agree on a single format for nested tests. This would allow for a cleaner specification of KTAP and would reduce possible confusion. ==== So what do people think about the above specification? How should we handle the differences with kselftests? If this specification is accepted, where should the specification be documented?

2 years, 2 months

7
13
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror December 2021