December 2023 - Linux-kselftest-mirror

[PATCH] selftests/hid: fix failing tablet button tests

by Benjamin Tissoires

An overlook from commit 74452d6329be ("selftests/hid: tablets: add variants of states with buttons"), where I don't use the Enum... Fixes: 74452d6329be ("selftests/hid: tablets: add variants of states with buttons") Signed-off-by: Benjamin Tissoires <bentiss(a)kernel.org> --- Not sure what happened, but I mustn't have run the tests before sending the series, and they fail blatently. I'm deeply sorry for that, I thought these failures were fixed. Cheers, Benjamin --- tools/testing/selftests/hid/tests/test_tablet.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/hid/tests/test_tablet.py b/tools/testing/selftests/hid/tests/test_tablet.py index dc8b0fe9e7f3..903f19f7cbe9 100644 --- a/tools/testing/selftests/hid/tests/test_tablet.py +++ b/tools/testing/selftests/hid/tests/test_tablet.py @@ -115,7 +115,7 @@ class PenState(Enum): # we take only the highest button in account for b in [libevdev.EV_KEY.BTN_STYLUS, libevdev.EV_KEY.BTN_STYLUS2]: if bool(evdev.value[b]): - button = b + button = BtnPressed(b) # the kernel tends to insert an EV_SYN once removing the tool, so # the button will be released after @@ -155,7 +155,7 @@ class PenState(Enum): if button_found: raise ValueError(f"duplicated BTN_STYLUS* in {events}") button_found = True - button = ev.code if ev.value else None + button = BtnPressed(ev.code) if ev.value else None # the kernel tends to insert an EV_SYN once removing the tool, so # the button will be released after --- base-commit: f556aa957df8cb3e98af0f54bf1fa65f59ae47a3 change-id: 20231207-b4-wip-selftests-c1565d4d4578 Best regards, -- Benjamin Tissoires <bentiss(a)kernel.org>

5 months, 2 weeks

2
2
0 0

[PATCH v2 00/15] selftests/hid: tablets fixes

by Benjamin Tissoires

Hi, the main trigger of this series was the XP-Pen issue[0]. Basically, the tablets tests were good-ish but couldn't handle that tablet both in terms of emulation or in terms of detection of issues. So rework the tablets test a bit to be able to include the XP-Pen patch later, once I have a kernel fix for it (right now I only have a HID-BPF fix, meaning that the test will fail if I include them). Also, vmtest.sh needed a little bit of care, because boot2container moved, and I made it easier to reuse in a CI environment. Cheers, Benjamin Note: I got the confirmation off-list from Peter that his rev-by applied to the whole series. [0] https://lore.kernel.org/all/nycvar.YFH.7.76.2311012033290.29220@cbobk.fhfr.… Signed-off-by: Benjamin Tissoires <bentiss(a)kernel.org> --- Changes in v2: - took Peter's review into account - Added a few patches to make mypy and ruff happy given that I had to add a couple of type hints here and there - Link to v1: https://lore.kernel.org/r/20231129-wip-selftests-v1-0-ba15a1fe1b0d@kernel.o… --- Benjamin Tissoires (15): selftests/hid: vmtest.sh: update vm2c and container selftests/hid: vmtest.sh: allow finer control on the build steps selftests/hid: base: allow for multiple skip_if_uhdev selftests/hid: tablets: remove unused class selftests/hid: tablets: move the transitions to PenState selftests/hid: tablets: move move_to function to PenDigitizer selftests/hid: tablets: do not set invert when the eraser is used selftests/hid: tablets: set initial data for tilt/twist selftests/hid: tablets: define the elements of PenState selftests/hid: tablets: add variants of states with buttons selftests/hid: tablets: convert the primary button tests selftests/hid: tablets: add a secondary barrel switch test selftests/hid: tablets: be stricter for some transitions selftests/hid: fix mypy complains selftests/hid: fix ruff linter complains tools/testing/selftests/hid/tests/base.py | 7 +- tools/testing/selftests/hid/tests/test_mouse.py | 14 +- tools/testing/selftests/hid/tests/test_tablet.py | 764 ++++++++++++++------- .../selftests/hid/tests/test_wacom_generic.py | 6 +- tools/testing/selftests/hid/vmtest.sh | 46 +- 5 files changed, 567 insertions(+), 270 deletions(-) --- base-commit: 4ea4ed22b57846facd9cb4af5f67cb7bd2792cf3 change-id: 20231121-wip-selftests-001ac427e086 Best regards, -- Benjamin Tissoires <bentiss(a)kernel.org>

5 months, 2 weeks

3
18
0 0

[PATCH v1] selftests/sgx: Skip non X86_64 platform

by Zhao Mengmeng

From: Zhao Mengmeng <zhaomengmeng(a)kylinos.cn> When building whole selftests on arm64, rsync gives an erorr about sgx: rsync: [sender] link_stat "/root/linux-next/tools/testing/selftests/sgx/test_encl.elf" failed: No such file or directory (2) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1327) [sender=3.2.5] The root casue is sgx only used on X86_64, and shall be skipped on other platforms. Fix this by moving TEST_CUSTOM_PROGS and TEST_FILES inside the if check, then the build result will be "Skipping non-existent dir: sgx". Fixes: 2adcba79e69d ("selftests/x86: Add a selftest for SGX") Signed-off-by: Zhao Mengmeng <zhaomengmeng(a)kylinos.cn> --- tools/testing/selftests/sgx/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/sgx/Makefile b/tools/testing/selftests/sgx/Makefile index 50aab6b57da3..01abe4969b0f 100644 --- a/tools/testing/selftests/sgx/Makefile +++ b/tools/testing/selftests/sgx/Makefile @@ -16,10 +16,10 @@ HOST_CFLAGS := -Wall -Werror -g $(INCLUDES) -fPIC -z noexecstack ENCL_CFLAGS := -Wall -Werror -static -nostdlib -nostartfiles -fPIC \ -fno-stack-protector -mrdrnd $(INCLUDES) +ifeq ($(CAN_BUILD_X86_64), 1) TEST_CUSTOM_PROGS := $(OUTPUT)/test_sgx TEST_FILES := $(OUTPUT)/test_encl.elf -ifeq ($(CAN_BUILD_X86_64), 1) all: $(TEST_CUSTOM_PROGS) $(OUTPUT)/test_encl.elf endif -- 2.38.1

5 months, 2 weeks

2
1
0 0

WARNING: CPU: 6 PID: 474 at include/linux/maple_tree.h:712 mmap_region (include/linux/maple_tree.h:556 include/linux/maple_tree.h:731

by Naresh Kamboju

Following kernel panic noticed while running selftests: exec: load_address on Fastmodels (FVP) running Linux next-20231109. Reported-by: Linux Kernel Functional Testing <lkft(a)linaro.org> log: --- # timeout set to 45 # selftests: exec: load_address_16777216 [ 238.405168] ------------[ cut here ]------------ [ 238.405244] WARNING: CPU: 6 PID: 474 at include/linux/maple_tree.h:712 mmap_region (include/linux/maple_tree.h:556 include/linux/maple_tree.h:731 include/linux/maple_tree.h:747 include/linux/mm.h:1033 mm/mmap.c:2828) [ 238.405432] Modules linked in: arm_spe_pmu crct10dif_ce panel_simple pl111_drm drm_dma_helper drm_kms_helper fuse drm backlight dm_mod ip_tables x_tables [ 238.405932] CPU: 6 PID: 474 Comm: load_address_16 Not tainted 6.6.0-next-20231109 #1 [ 238.406070] Hardware name: FVP Base RevC (DT) [ 238.406151] pstate: 123402009 (nzCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) [ 238.406294] pc : mmap_region (include/linux/maple_tree.h:556 include/linux/maple_tree.h:731 include/linux/maple_tree.h:747 include/linux/mm.h:1033 mm/mmap.c:2828) [ 238.406424] lr : mmap_region (mm/mmap.c:2836) [ 238.406554] sp : ffff8000819639b0 [ 238.406629] x29: ffff8000819639c0 x28: ffff000806f79000 x27: 0000000002002000 [ 238.406829] x26: ffff000806f798f0 x25: ffff000806f790b0 x24: 0000000000000006 [ 238.407029] x23: 0000000000000ffc x22: ffff000805d6e100 x21: ffff0008016adf00 [ 238.407229] x20: 0000000000100073 x19: 0000000001ffc000 x18: ffffffffffffffff [ 238.407425] x17: 0000000000000000 x16: ffffd7c64ceb7c10 x15: ffffffffffffffff [ 238.407627] x14: 0000000000000000 x13: 1fffe001002bc9a1 x12: ffff0008015e4d0c [ 238.407825] x11: ffff800081963a48 x10: ffff0008015e4d00 x9 : ffffd7c64b49c9f0 [ 238.408028] x8 : ffff800081963778 x7 : 0000000000000000 x6 : 0000000000000000 [ 238.408223] x5 : ffffd7c64e35f000 x4 : ffffd7c64e35f278 x3 : 0000000000000000 [ 238.408420] x2 : ffffd7c64e92fd78 x1 : 0000000002001fff x0 : 0000000000479fff [ 238.408618] Call trace: [ 238.408681] mmap_region (include/linux/maple_tree.h:556 include/linux/maple_tree.h:731 include/linux/maple_tree.h:747 include/linux/mm.h:1033 mm/mmap.c:2828) [ 238.408812] do_mmap (arch/arm64/include/asm/mman.h:18 include/linux/mman.h:147 mm/mmap.c:1274) [ 238.408940] vm_mmap_pgoff (mm/util.c:546) [ 238.409088] vm_mmap (mm/util.c:559) [ 238.409229] elf_load (fs/binfmt_elf.c:385 fs/binfmt_elf.c:408) [ 238.409337] load_elf_binary (fs/binfmt_elf.c:1134 (discriminator 1)) [ 238.409454] bprm_execve (fs/exec.c:1940) [ 238.409598] do_execveat_common.isra.0 (fs/exec.c:1938) [ 238.409757] __arm64_sys_execve (fs/exec.c:2106) [ 238.409910] invoke_syscall (arch/arm64/kernel/syscall.c:46 (discriminator 19)) [ 238.410058] el0_svc_common.constprop.0 (arch/arm64/kernel/syscall.c:136) [ 238.410218] do_el0_svc (arch/arm64/kernel/syscall.c:155) [ 238.410363] el0_svc (arch/arm64/include/asm/daifflags.h:75 arch/arm64/kernel/entry-common.c:677) [ 238.410508] el0t_64_sync_handler (arch/arm64/kernel/entry-common.c:697) [ 238.410623] el0t_64_sync (arch/arm64/kernel/entry.S:595) [ 238.410735] ---[ end trace 0000000000000000 ]--- Links: - https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20231109/te… - https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20231109/te… - https://tuxapi.tuxsuite.com/v1/groups/linaro/projects/lkft/tests/2Xv9wca3SP… - https://storage.tuxsuite.com/public/linaro/lkft/builds/2Xv9vEpjybxlDA4IvgDB… -- Linaro LKFT https://lkft.linaro.org

5 months, 2 weeks

5
4
0 0

hi

by mohams

hi my friend

5 months, 2 weeks

1
0
0 0

[PATCH v1 0/9] x86/resctrl: Use soft RMIDs for reliable MBM on AMD

by Peter Newman

Hi Reinette, Fenghua, This series introduces a new mount option enabling an alternate mode for MBM to work around an issue on present AMD implementations and any other resctrl implementation where there are more RMIDs (or equivalent) than hardware counters. The L3 External Bandwidth Monitoring feature of the AMD PQoS extension[1] only guarantees that RMIDs currently assigned to a processor will be tracked by hardware. The counters of any other RMIDs which are no longer being tracked will be reset to zero. The MBM event counters return "Unavailable" to indicate when this has happened. An interval for effectively measuring memory bandwidth typically needs to be multiple seconds long. In Google's workloads, it is not feasible to bound the number of jobs with different RMIDs which will run in a cache domain over any period of time. Consequently, on a fully-committed system where all RMIDs are allocated, few groups' counters return non-zero values. To demonstrate the underlying issue, the first patch provides a test case in tools/testing/selftests/resctrl/test_rmids.sh. On an AMD EPYC 7B12 64-Core Processor with the default behavior: # ./test_rmids.sh Created 255 monitoring groups. g1: mbm_total_bytes: Unavailable -> Unavailable (FAIL) g2: mbm_total_bytes: Unavailable -> Unavailable (FAIL) g3: mbm_total_bytes: Unavailable -> Unavailable (FAIL) [..] g238: mbm_total_bytes: Unavailable -> Unavailable (FAIL) g239: mbm_total_bytes: Unavailable -> Unavailable (FAIL) g240: mbm_total_bytes: Unavailable -> Unavailable (FAIL) g241: mbm_total_bytes: Unavailable -> 660497472 g242: mbm_total_bytes: Unavailable -> 660793344 g243: mbm_total_bytes: Unavailable -> 660477312 g244: mbm_total_bytes: Unavailable -> 660495360 g245: mbm_total_bytes: Unavailable -> 660775360 g246: mbm_total_bytes: Unavailable -> 660645504 g247: mbm_total_bytes: Unavailable -> 660696128 g248: mbm_total_bytes: Unavailable -> 660605248 g249: mbm_total_bytes: Unavailable -> 660681280 g250: mbm_total_bytes: Unavailable -> 660834240 g251: mbm_total_bytes: Unavailable -> 660440064 g252: mbm_total_bytes: Unavailable -> 660501504 g253: mbm_total_bytes: Unavailable -> 660590720 g254: mbm_total_bytes: Unavailable -> 660548352 g255: mbm_total_bytes: Unavailable -> 660607296 255 groups, 0 returned counts in first pass, 15 in second successfully measured bandwidth from 15/255 groups To compare, here is the output from an Intel(R) Xeon(R) Platinum 8173M CPU: # ./test_rmids.sh Created 223 monitoring groups. g1: mbm_total_bytes: 0 -> 606126080 g2: mbm_total_bytes: 0 -> 613236736 g3: mbm_total_bytes: 0 -> 610254848 [..] g221: mbm_total_bytes: 0 -> 584679424 g222: mbm_total_bytes: 0 -> 588808192 g223: mbm_total_bytes: 0 -> 587317248 223 groups, 223 returned counts in first pass, 223 in second successfully measured bandwidth from 223/223 groups To make better use of the hardware in such a use case, this patchset introduces a "soft" RMID implementation, where each CPU is permanently assigned a "hard" RMID. On context switches which change the current soft RMID, the difference between each CPU's current event counts and most recent counts is added to the totals for the current or outgoing soft RMID. This technique does not work for cache occupancy counters, so this patch series disables cache occupancy events when soft RMIDs are enabled. This series adds the "mbm_soft_rmid" mount option to allow users to opt-in to the functionaltiy when they deem it helpful. When the same system from the earlier AMD example enables the mbm_soft_rmid mount option: # ./test_rmids.sh Created 255 monitoring groups. g1: mbm_total_bytes: 0 -> 686560576 g2: mbm_total_bytes: 0 -> 668204416 [..] g252: mbm_total_bytes: 0 -> 672651200 g253: mbm_total_bytes: 0 -> 666956800 g254: mbm_total_bytes: 0 -> 665917056 g255: mbm_total_bytes: 0 -> 671049600 255 groups, 255 returned counts in first pass, 255 in second successfully measured bandwidth from 255/255 groups (patches are based on tip/master) [1] https://www.amd.com/system/files/TechDocs/56375_1.03_PUB.pdf Peter Newman (8): selftests/resctrl: Verify all RMIDs count together x86/resctrl: Add resctrl_mbm_flush_cpu() to collect CPUs' MBM events x86/resctrl: Flush MBM event counts on soft RMID change x86/resctrl: Call mon_event_count() directly for soft RMIDs x86/resctrl: Create soft RMID version of __mon_event_count() x86/resctrl: Assign HW RMIDs to CPUs for soft RMID x86/resctrl: Use mbm_update() to push soft RMID counts x86/resctrl: Add mount option to enable soft RMID Stephane Eranian (1): x86/resctrl: Hold a spinlock in __rmid_read() on AMD arch/x86/include/asm/resctrl.h | 29 +++- arch/x86/kernel/cpu/resctrl/core.c | 80 ++++++++- arch/x86/kernel/cpu/resctrl/ctrlmondata.c | 9 +- arch/x86/kernel/cpu/resctrl/internal.h | 19 ++- arch/x86/kernel/cpu/resctrl/monitor.c | 158 +++++++++++++++++- arch/x86/kernel/cpu/resctrl/rdtgroup.c | 52 ++++++ tools/testing/selftests/resctrl/test_rmids.sh | 93 +++++++++++ 7 files changed, 425 insertions(+), 15 deletions(-) create mode 100755 tools/testing/selftests/resctrl/test_rmids.sh base-commit: dd806e2f030e57dd5bac973372aa252b6c175b73 -- 2.40.0.634.g4ca3ef3211-goog

5 months, 2 weeks

2
39
0 0

hi

by mohams

hi my friend

5 months, 2 weeks

1
0
0 0

hi

by mohams

hi my friend

5 months, 2 weeks

1
0
0 0

hi

by mohams

hi my friend

5 months, 2 weeks

1
0
0 0

[PATCH v2] kunit: run test suites only after module initialization completes

by Marco Pagani

Commit 2810c1e99867 ("kunit: Fix wild-memory-access bug in kunit_free_suite_set()") fixed a wild-memory-access bug that could have happened during the loading phase of test suites built and executed as loadable modules. However, it also introduced a problematic side effect that causes test suites modules to crash when they attempt to register fake devices. When a module is loaded, it traverses the MODULE_STATE_UNFORMED and MODULE_STATE_COMING states before reaching the normal operating state MODULE_STATE_LIVE. Finally, when the module is removed, it moves to MODULE_STATE_GOING before being released. However, if the loading function load_module() fails between complete_formation() and do_init_module(), the module goes directly from MODULE_STATE_COMING to MODULE_STATE_GOING without passing through MODULE_STATE_LIVE. This behavior was causing kunit_module_exit() to be called without having first executed kunit_module_init(). Since kunit_module_exit() is responsible for freeing the memory allocated by kunit_module_init() through kunit_filter_suites(), this behavior was resulting in a wild-memory-access bug. Commit 2810c1e99867 ("kunit: Fix wild-memory-access bug in kunit_free_suite_set()") fixed this issue by running the tests when the module is still in MODULE_STATE_COMING. However, modules in that state are not fully initialized, lacking sysfs kobjects. Therefore, if a test module attempts to register a fake device, it will inevitably crash. This patch proposes a different approach to fix the original wild-memory-access bug while restoring the normal module execution flow by making kunit_module_exit() able to detect if kunit_module_init() has previously initialized the tests suite set. In this way, test modules can once again register fake devices without crashing. This behavior is achieved by checking whether mod->kunit_suites is a virtual or direct mapping address. If it is a virtual address, then kunit_module_init() has allocated the suite_set in kunit_filter_suites() using kmalloc_array(). On the contrary, if mod->kunit_suites is still pointing to the original address that was set when looking up the .kunit_test_suites section of the module, then the loading phase has failed and there's no memory to be freed. v2: - add include <linux/mm.h> Fixes: 2810c1e99867 ("kunit: Fix wild-memory-access bug in kunit_free_suite_set()") Signed-off-by: Marco Pagani <marpagan(a)redhat.com> --- lib/kunit/test.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/lib/kunit/test.c b/lib/kunit/test.c index f2eb71f1a66c..0e829b9f8ce5 100644 --- a/lib/kunit/test.c +++ b/lib/kunit/test.c @@ -16,6 +16,7 @@ #include <linux/panic.h> #include <linux/sched/debug.h> #include <linux/sched.h> +#include <linux/mm.h> #include "debugfs.h" #include "hooks-impl.h" @@ -737,12 +738,14 @@ static void kunit_module_exit(struct module *mod) }; const char *action = kunit_action(); + if (!suite_set.start || !virt_addr_valid(suite_set.start)) + return; + if (!action) __kunit_test_suites_exit(mod->kunit_suites, mod->num_kunit_suites); - if (suite_set.start) - kunit_free_suite_set(suite_set); + kunit_free_suite_set(suite_set); } static int kunit_module_notify(struct notifier_block *nb, unsigned long val, @@ -752,12 +755,12 @@ static int kunit_module_notify(struct notifier_block *nb, unsigned long val, switch (val) { case MODULE_STATE_LIVE: + kunit_module_init(mod); break; case MODULE_STATE_GOING: kunit_module_exit(mod); break; case MODULE_STATE_COMING: - kunit_module_init(mod); break; case MODULE_STATE_UNFORMED: break; base-commit: 2cc14f52aeb78ce3f29677c2de1f06c0e91471ab -- 2.42.0

5 months, 2 weeks

3
3
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror December 2023