October 2024 - Linux-kselftest-mirror

[PATCH V4 00/15] selftests/resctrl: Support diverse platforms with MBM and MBA tests

by Reinette Chatre

Changes since V3: - V3: https://lore.kernel.org/all/cover.1729218182.git.reinette.chatre@intel.com/ - Rebased on HEAD 2a027d6bb660 of kselftest/next. - Fix empty string parsing issues pointed out by Ilpo. - Add Reviewed-by tags. - Please see individual patches for detailed changes. Changes since V2: - V2: https://lore.kernel.org/all/cover.1726164080.git.reinette.chatre@intel.com/ - Add fix to protect against buffer overflow when parsing text from sysfs files. - Add cleanup patch to address use of magic constants as pointed out by Ilpo. - Add Reviewed-by tags where received, except for "selftests/resctrl: Use cache size to determine "fill_buf" buffer size" that changed too much since receiving the Reviewed-by tag. - Please see individual patches for detailed changes. Changes since V1: - V1: https://lore.kernel.org/cover.1724970211.git.reinette.chatre@intel.com/ - V2 contains the same general solutions to stated problem as V1 but these are now preceded by more fixes (patches 1 to 5) and improved robustness (patches 6 to 9) to existing tests before the series gets back to solving the original problem with more confidence in patches 10 to 13. - The posibility of making "memflush = false" for CMT test was discussed during V1. Modifying this setting does not have a significant impact on the observed results that are already well within acceptable range and this version thus keeps original default. If performance was a goal it may be possible to do further experimentation where "memflush = false" could eliminate the need for the sleep(1) within the test wrapper, but improving the performance is not a goal of this work. - (New) Support what seems to be unintended ability for user space to provide parameters to "fill_buf" by making the parsing robust and only support changing parameters that are supported to be changed. Drop support for "write" operation since it has never been measured. - (New) Improve wraparound handling. (Ilpo) - (New) A couple of new fixes addressing issues discovered during development. - (Change from V1) To support fill_buf parameters provided by user space as well as test specific fill_buf parameters struct fill_buf_param is no longer just a member of struct resctrl_val_param, instead there could be at most two instances of struct fill_buf_param, the immutable parameters provided by user space and the parameters used by individual tests. (Ilpo) - Please see individual patches for detailed changes. V1 cover: The resctrl selftests for Memory Bandwidth Allocation (MBA) and Memory Bandwidth Monitoring (MBM) are failing on some (for example [1]) Emerald Rapids systems. The test failures result from the following two properties of these systems: 1) Emerald Rapids systems can have up to 320MB L3 cache. The resctrl MBA and MBM selftests measure memory traffic for which a hardcoded 250MB buffer has been sufficient so far. On platforms with L3 cache larger than the buffer, the buffer fits in the L3 cache and thus no/very little memory traffic is generated during the "memory bandwidth" tests. 2) Some platform features, for example RAS features or memory performance features that generate memory traffic may drive accesses that are counted differently by performance counters and MBM respectively, for instance generating "overhead" traffic which is not counted against any specific RMID. Until now these counting differences have always been "in the noise". On Emerald Rapids systems the maximum MBA throttling (10% memory bandwidth) throttles memory bandwidth to where memory accesses by these other platform features push the memory bandwidth difference between memory controller performance counters and resctrl (MBM) beyond the tests' hardcoded tolerance. Make the tests more robust against platform variations: 1) Let the buffer used by memory bandwidth tests be guided by the size of the L3 cache. 2) Larger buffers require longer initialization time before the buffer can be used to measurement. Rework the tests to ensure that buffer initialization is complete before measurements start. 3) Do not compare performance counters and MBM measurements at low bandwidth. The value of "low" is hardcoded to 750MiB based on measurements on Emerald Rapids, Sapphire Rapids, and Ice Lake systems. This limit is not applicable to AMD systems since it only applies to the MBA and MBM tests that are isolated to Intel. [1] https://ark.intel.com/content/www/us/en/ark/products/237261/intel-xeon-plat… Reinette Chatre (15): selftests/resctrl: Make functions only used in same file static selftests/resctrl: Print accurate buffer size as part of MBM results selftests/resctrl: Fix memory overflow due to unhandled wraparound selftests/resctrl: Protect against array overrun during iMC config parsing selftests/resctrl: Protect against array overflow when reading strings selftests/resctrl: Make wraparound handling obvious selftests/resctrl: Remove "once" parameter required to be false selftests/resctrl: Only support measured read operation selftests/resctrl: Remove unused measurement code selftests/resctrl: Make benchmark parameter passing robust selftests/resctrl: Ensure measurements skip initialization of default benchmark selftests/resctrl: Use cache size to determine "fill_buf" buffer size selftests/resctrl: Do not compare performance counters and resctrl at low bandwidth selftests/resctrl: Keep results from first test run selftests/resctrl: Replace magic constants used as array size tools/testing/selftests/resctrl/cmt_test.c | 37 +- tools/testing/selftests/resctrl/fill_buf.c | 45 +- tools/testing/selftests/resctrl/mba_test.c | 54 ++- tools/testing/selftests/resctrl/mbm_test.c | 37 +- tools/testing/selftests/resctrl/resctrl.h | 79 +++- .../testing/selftests/resctrl/resctrl_tests.c | 95 +++- tools/testing/selftests/resctrl/resctrl_val.c | 447 +++++------------- tools/testing/selftests/resctrl/resctrlfs.c | 19 +- 8 files changed, 354 insertions(+), 459 deletions(-) base-commit: 2a027d6bb66002c8e50e974676f932b33c5fce10 -- 2.47.0

9 months, 3 weeks

3
26
0 0

[PATCH v3 0/5] Improve arm64 pkeys handling in signal delivery

by Kevin Brodsky

This series is a follow-up to Joey's Permission Overlay Extension (POE) series [1] that recently landed on mainline. The goal is to improve the way we handle the register that governs which pkeys/POIndex are accessible (POR_EL0) during signal delivery. As things stand, we may unexpectedly fail to write the signal frame on the stack because POR_EL0 is not reset before the uaccess operations. See patch 1 for more details and the main changes this series brings. A similar series landed recently for x86/MPK [2]; the present series aims at aligning arm64 with x86. Worth noting: once the signal frame is written, POR_EL0 is still set to POR_EL0_INIT, granting access to pkey 0 only. This means that a program that sets up an alternate signal stack with a non-zero pkey will need some assembly trampoline to set POR_EL0 before invoking the real signal handler, as discussed here [3]. This is not ideal, but it makes experimentation with pkeys in signal handlers possible while waiting for a potential interface to control the pkey state when delivering a signal. See Pierre's reply [4] for more information about use-cases and a potential interface. The x86 series also added kselftests to ensure that no spurious SIGSEGV occurs during signal delivery regardless of which pkey is accessible at the point where the signal is delivered. This series adapts those kselftests to allow running them on arm64 (patch 4-5). There is a dependency on Yury's PKEY_UNRESTRICTED patch [7] for patch 4 specifically. Finally patch 2 is a clean-up following feedback on Joey's series [5]. I have tested this series on arm64 and x86_64 (booting and running the protection_keys and pkey_sighandler_tests mm kselftests). - Kevin --- v2..v3: * Reordered patches (patch 1 is now the main patch). * Patch 1: compute por_enable_all with an explicit loop, based on arch_max_pkey() (suggestion from Dave M). * Patch 4: improved naming, replaced global pkey reg value with inline helper, made use of Yury's PKEY_UNRESTRICTED macro [7] (suggestions from Dave H). v2: https://lore.kernel.org/linux-arm-kernel/20241023150511.3923558-1-kevin.bro… v1..v2: * In setup_rt_frame(), ensured that POR_EL0 is reset to its original value if we fail to deliver the signal (addresses Catalin's concern [6]). * Renamed *unpriv_access* to *user_access* in patch 3 (suggestion from Dave). * Made what patch 1-2 do explicit in the commit message body (suggestion from Dave). v1: https://lore.kernel.org/linux-arm-kernel/20241017133909.3837547-1-kevin.bro… [1] https://lore.kernel.org/linux-arm-kernel/20240822151113.1479789-1-joey.goul… [2] https://lore.kernel.org/lkml/20240802061318.2140081-1-aruna.ramakrishna@ora… [3] https://lore.kernel.org/lkml/CABi2SkWxNkP2O7ipkP67WKz0-LV33e5brReevTTtba6oK… [4] https://lore.kernel.org/linux-arm-kernel/87plns8owh.fsf@arm.com/ [5] https://lore.kernel.org/linux-arm-kernel/20241015114116.GA19334@willie-the-… [6] https://lore.kernel.org/linux-arm-kernel/Zw6D2waVyIwYE7wd@arm.com/ [7] https://lore.kernel.org/all/20241028090715.509527-2-yury.khrustalev@arm.com/ Cc: akpm(a)linux-foundation.org Cc: anshuman.khandual(a)arm.com Cc: aruna.ramakrishna(a)oracle.com Cc: broonie(a)kernel.org Cc: catalin.marinas(a)arm.com Cc: dave.hansen(a)linux.intel.com Cc: Dave.Martin(a)arm.com Cc: jeffxu(a)chromium.org Cc: joey.gouly(a)arm.com Cc: keith.lucas(a)oracle.com Cc: pierre.langlois(a)arm.com Cc: shuah(a)kernel.org Cc: sroettger(a)google.com Cc: tglx(a)linutronix.de Cc: will(a)kernel.org Cc: yury.khrustalev(a)arm.com Cc: linux-kselftest(a)vger.kernel.org Cc: x86(a)kernel.org Kevin Brodsky (5): arm64: signal: Improve POR_EL0 handling to avoid uaccess failures arm64: signal: Remove unnecessary check when saving POE state arm64: signal: Remove unused macro selftests/mm: Use generic pkey register manipulation selftests/mm: Enable pkey_sighandler_tests on arm64 arch/arm64/kernel/signal.c | 95 ++++++++++++--- tools/testing/selftests/mm/Makefile | 8 +- tools/testing/selftests/mm/pkey-arm64.h | 1 + tools/testing/selftests/mm/pkey-x86.h | 2 + .../selftests/mm/pkey_sighandler_tests.c | 115 ++++++++++++++---- 5 files changed, 176 insertions(+), 45 deletions(-) -- 2.43.0

9 months, 3 weeks

5
16
0 0

[PATCH v6 0/6] Add PSCI v1.3 SYSTEM_OFF2 support for hibernation

by David Woodhouse

The PSCI v1.3 spec (https://developer.arm.com/documentation/den0022) adds support for a SYSTEM_OFF2 function enabling a HIBERNATE_OFF state which is analogous to ACPI S4. This will allow hosting environments to determine that a guest is hibernated rather than just powered off, and ensure that they preserve the virtual environment appropriately to allow the guest to resume safely (or bump the hardware_signature in the FACS to trigger a clean reboot instead). This updates KVM to support advertising PSCI v1.3, and unconditionally enables the SYSTEM_OFF2 support when PSCI v1.3 is enabled. For the guest side, add a new SYS_OFF_MODE_POWER_OFF handler with higher priority than the EFI one, but which *only* triggers when there's a hibernation in progress. There are other ways to do this (see the commit message for more details) but this seemed like the simplest. Version 2 of the patch series splits out the psci.h definitions into a separate commit (a dependency for both the guest and KVM side), and adds definitions for the other new functions added in v1.3. It also moves the pKVM psci-relay support to a separate commit; although in arch/arm64/kvm that's actually about the *guest* side of SYSTEM_OFF2 (i.e. using it from the host kernel, relayed through nVHE). Version 3 dropped the KVM_CAP which allowed userspace to explicitly opt in to the new feature like with SYSTEM_SUSPEND, and makes it depend only on PSCI v1.3 being exposed to the guest. Version 4 is no longer RFC, as the PSCI v1.3 spec is finally published. Minor fixes from the last round of review, and an added KVM self test. Version 5 drops some of the changes which didn't make it to the final v1.3 spec, and cleans up a couple of places which still referred to it as 'alpha' or 'beta'. It also temporarily drops the guest-side patch to invoke SYSTEM_OFF2 for hibernation, pending confirmation that the final PSCI v1.3 spec just has a typo where it changed to saying that 0x1 should be passed to mean HIBERNATE_OFF, even though it's advertised as bit 0. That can be sent under separate cover, and perhaps should have been anyway. The change in question doesn't matter for any of the KVM patches, because we just treat SYSTEM_OFF2 like the existing SYSTEM_RESET2, setting a flag to indicate that it was a SYSTEM_OFF2 call, but not actually caring about the argument; that's for userspace to worry about. Version 6 is updated to revision F.b of the specification, allowing both 0x0 and 0x1 to indicate HIBERNATE_OFF in the SYSTEM_OFF2 call, as well as disallowing anything but zero in the second argument. The test is expanded to cover those variants, and to require PSCI v1.3 instead of skipping on older kernels. The final guest-side patch in the series is reinstated, using zero as the argument for compatibility with existing hypervisors in the field as permitted by revision F.b. allows for zero as well as 0x1 for HIBERNATE_OFF to accommodate the change in the final version of the spec, and expands the test to cover both forms as well as checking that a non-zero second argument is correctly rejected. David Woodhouse (6): firmware/psci: Add definitions for PSCI v1.3 specification KVM: arm64: Add PSCI v1.3 SYSTEM_OFF2 function for hibernation KVM: arm64: Add support for PSCI v1.2 and v1.3 KVM: selftests: Add test for PSCI SYSTEM_OFF2 KVM: arm64: nvhe: Pass through PSCI v1.3 SYSTEM_OFF2 call arm64: Use SYSTEM_OFF2 PSCI call to power off for hibernate Documentation/virt/kvm/api.rst | 11 +++ arch/arm64/include/uapi/asm/kvm.h | 6 ++ arch/arm64/kvm/hyp/nvhe/psci-relay.c | 2 + arch/arm64/kvm/hypercalls.c | 2 + arch/arm64/kvm/psci.c | 50 ++++++++++++- drivers/firmware/psci/psci.c | 42 +++++++++++ include/kvm/arm_psci.h | 4 +- include/uapi/linux/psci.h | 5 ++ kernel/power/hibernate.c | 5 +- tools/testing/selftests/kvm/aarch64/psci_test.c | 93 +++++++++++++++++++++++++ 10 files changed, 217 insertions(+), 3 deletions(-)

9 months, 3 weeks

6
28
0 0

[PATCH v3] selftests: clone3: Use the capget and capset syscall directly

by zhouyuhang

From: zhouyuhang <zhouyuhang(a)kylinos.cn> The libcap commit aca076443591 ("Make cap_t operations thread safe.") added a __u8 mutex at the beginning of the struct _cap_struct, it changes the offset of the members in the structure that breaks the assumption made in the "struct libcap" definition in clone3_cap_checkpoint_restore.c. This will cause the test case to fail with the following output: # RUN global.clone3_cap_checkpoint_restore ... # clone3() syscall supported # clone3_cap_checkpoint_restore.c:151:clone3_cap_checkpoint_restore:Child has PID 130508 cap_set_proc: Operation not permitted # clone3_cap_checkpoint_restore.c:160:clone3_cap_checkpoint_restore:Expected set_capability() (-1) == 0 (0) # clone3_cap_checkpoint_restore.c:161:clone3_cap_checkpoint_restore:Could not set CAP_CHECKPOINT_RESTORE # clone3_cap_checkpoint_restore: Test terminated by assertion # FAIL global.clone3_cap_checkpoint_restore Changing to using capget and capset syscall directly here can fix this error, just like what the commit 663af70aabb7 ("bpf: selftests: Add helpers to directly use the capget and capset syscall") does. Signed-off-by: zhouyuhang <zhouyuhang(a)kylinos.cn> --- .../clone3/clone3_cap_checkpoint_restore.c | 58 +++++++++---------- 1 file changed, 27 insertions(+), 31 deletions(-) diff --git a/tools/testing/selftests/clone3/clone3_cap_checkpoint_restore.c b/tools/testing/selftests/clone3/clone3_cap_checkpoint_restore.c index 3c196fa86c99..8b61702bf721 100644 --- a/tools/testing/selftests/clone3/clone3_cap_checkpoint_restore.c +++ b/tools/testing/selftests/clone3/clone3_cap_checkpoint_restore.c @@ -27,6 +27,13 @@ #include "../kselftest_harness.h" #include "clone3_selftests.h" +/* + * Prevent not being defined in the header file + */ +#ifndef CAP_CHECKPOINT_RESTORE +#define CAP_CHECKPOINT_RESTORE 40 +#endif + static void child_exit(int ret) { fflush(stdout); @@ -87,47 +94,36 @@ static int test_clone3_set_tid(struct __test_metadata *_metadata, return ret; } -struct libcap { - struct __user_cap_header_struct hdr; - struct __user_cap_data_struct data[2]; -}; - static int set_capability(void) { - cap_value_t cap_values[] = { CAP_SETUID, CAP_SETGID }; - struct libcap *cap; - int ret = -1; - cap_t caps; - - caps = cap_get_proc(); - if (!caps) { - perror("cap_get_proc"); + struct __user_cap_data_struct data[2]; + struct __user_cap_header_struct hdr = { + .version = _LINUX_CAPABILITY_VERSION_3, + }; + __u32 cap0 = 1 << CAP_SETUID | 1 << CAP_SETGID; + __u32 cap1 = 1 << (CAP_CHECKPOINT_RESTORE - 32); + int ret; + + ret = capget(&hdr, data); + if (ret) { + perror("capget"); return -1; } /* Drop all capabilities */ - if (cap_clear(caps)) { - perror("cap_clear"); - goto out; - } - - cap_set_flag(caps, CAP_EFFECTIVE, 2, cap_values, CAP_SET); - cap_set_flag(caps, CAP_PERMITTED, 2, cap_values, CAP_SET); + memset(&data, 0, sizeof(data)); - cap = (struct libcap *) caps; + data[0].effective |= cap0; + data[0].permitted |= cap0; - /* 40 -> CAP_CHECKPOINT_RESTORE */ - cap->data[1].effective |= 1 << (40 - 32); - cap->data[1].permitted |= 1 << (40 - 32); + data[1].effective |= cap1; + data[1].permitted |= cap1; - if (cap_set_proc(caps)) { - perror("cap_set_proc"); - goto out; + ret = capset(&hdr, data); + if (ret) { + perror("capset"); + return -1; } - ret = 0; -out: - if (cap_free(caps)) - perror("cap_free"); return ret; } -- 2.27.0

9 months, 3 weeks

2
2
0 0

[PATCH 0/2] kunit: enable hardware virtualization

by Tamir Duberstein

This series implements feature detection of hardware virtualization on Linux and macOS; the latter being my primary use case. This yields approximately a 6x improvement using HVF on M3 Pro. Signed-off-by: Tamir Duberstein <tamird(a)gmail.com> --- Tamir Duberstein (2): kunit: add fallback for os.sched_getaffinity kunit: enable hardware acceleration when available tools/testing/kunit/kunit.py | 11 ++++++++++- tools/testing/kunit/kunit_kernel.py | 26 +++++++++++++++++++++++++- tools/testing/kunit/qemu_configs/arm64.py | 2 +- 3 files changed, 36 insertions(+), 3 deletions(-) --- base-commit: ae90f6a6170d7a7a1aa4fddf664fbd093e3023bc change-id: 20241025-kunit-qemu-accel-macos-2840e4c2def5 Best regards, -- Tamir Duberstein <tamird(a)gmail.com>

9 months, 3 weeks

3
6
0 0

[PATCH] kselftest/arm64: Use ksft_perror() to log MTE failures

by Mark Brown

The logging in the allocation helpers variously uses ksft_print_msg() with very intermittent logging of errno and perror() (which won't produce KTAP conformant output) when logging the result of API calls that set errno. Standardise on using the ksft_perror() helper in these cases so that more information is available should the tests fail. Signed-off-by: Mark Brown <broonie(a)kernel.org> --- tools/testing/selftests/arm64/mte/mte_common_util.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/tools/testing/selftests/arm64/mte/mte_common_util.c b/tools/testing/selftests/arm64/mte/mte_common_util.c index 00ffd34c66d301ee7d5c99e6b8d9d5d944520b7f..46958b58801e90ceb79be76f57c7f72b50d43b3c 100644 --- a/tools/testing/selftests/arm64/mte/mte_common_util.c +++ b/tools/testing/selftests/arm64/mte/mte_common_util.c @@ -150,13 +150,13 @@ static void *__mte_allocate_memory_range(size_t size, int mem_type, int mapping, map_flag |= MAP_PRIVATE; ptr = mmap(NULL, entire_size, prot_flag, map_flag, fd, 0); if (ptr == MAP_FAILED) { - ksft_print_msg("FAIL: mmap allocation\n"); + ksft_perror("mmap()"); return NULL; } if (mem_type == USE_MPROTECT) { if (mprotect(ptr, entire_size, prot_flag | PROT_MTE)) { + ksft_perror("mprotect(PROT_MTE)"); munmap(ptr, size); - ksft_print_msg("FAIL: mprotect PROT_MTE property\n"); return NULL; } } @@ -190,13 +190,13 @@ void *mte_allocate_file_memory(size_t size, int mem_type, int mapping, bool tags lseek(fd, 0, SEEK_SET); for (index = INIT_BUFFER_SIZE; index < size; index += INIT_BUFFER_SIZE) { if (write(fd, buffer, INIT_BUFFER_SIZE) != INIT_BUFFER_SIZE) { - perror("initialising buffer"); + ksft_perror("initialising buffer"); return NULL; } } index -= INIT_BUFFER_SIZE; if (write(fd, buffer, size - index) != size - index) { - perror("initialising buffer"); + ksft_perror("initialising buffer"); return NULL; } return __mte_allocate_memory_range(size, mem_type, mapping, 0, 0, tags, fd); @@ -217,12 +217,12 @@ void *mte_allocate_file_memory_tag_range(size_t size, int mem_type, int mapping, lseek(fd, 0, SEEK_SET); for (index = INIT_BUFFER_SIZE; index < map_size; index += INIT_BUFFER_SIZE) if (write(fd, buffer, INIT_BUFFER_SIZE) != INIT_BUFFER_SIZE) { - perror("initialising buffer"); + ksft_perror("initialising buffer"); return NULL; } index -= INIT_BUFFER_SIZE; if (write(fd, buffer, map_size - index) != map_size - index) { - perror("initialising buffer"); + ksft_perror("initialising buffer"); return NULL; } return __mte_allocate_memory_range(size, mem_type, mapping, range_before, @@ -359,7 +359,7 @@ int create_temp_file(void) /* Create a file in the tmpfs filesystem */ fd = mkstemp(&filename[0]); if (fd == -1) { - perror(filename); + ksft_perror(filename); ksft_print_msg("FAIL: Unable to open temporary file\n"); return 0; } --- base-commit: 8e929cb546ee42c9a61d24fae60605e9e3192354 change-id: 20241028-arm64-mte-test-logging-6c6e737b1c62 Best regards, -- Mark Brown <broonie(a)kernel.org>

9 months, 3 weeks

3
2
0 0

[PATCH] kselftest/arm64: Fix encoding for SVE B16B16 test

by Mark Brown

The test for SVE_B16B16 had a cut'n'paste of a SME instruction, fix it with a relevant SVE instruction. Fixes: 44d10c27bd75 ("kselftest/arm64: Add 2023 DPISA hwcap test coverage") Signed-off-by: Mark Brown <broonie(a)kernel.org> --- tools/testing/selftests/arm64/abi/hwcap.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/arm64/abi/hwcap.c b/tools/testing/selftests/arm64/abi/hwcap.c index f2d6007a2b983eba77a880ec7e614396a6cb1377..1e4ed89802f76c2bcbe4bfd1a9a987970db8b97d 100644 --- a/tools/testing/selftests/arm64/abi/hwcap.c +++ b/tools/testing/selftests/arm64/abi/hwcap.c @@ -361,8 +361,8 @@ static void sveaes_sigill(void) static void sveb16b16_sigill(void) { - /* BFADD ZA.H[W0, 0], {Z0.H-Z1.H} */ - asm volatile(".inst 0xC1E41C00" : : : ); + /* BFADD Z0.H, Z0.H, Z0.H */ + asm volatile(".inst 0x65000000" : : : ); } static void svepmull_sigill(void) --- base-commit: 8e929cb546ee42c9a61d24fae60605e9e3192354 change-id: 20241024-arm64-b16b16-test-a1c7bad2478e Best regards, -- Mark Brown <broonie(a)kernel.org>

9 months, 3 weeks

2
1
0 0

[PATCH RFC v2 0/5] Verify bias functionality for pinctrl_paris driver through new gpio test

by Nícolas F. R. A. Prado

This series was motivated by the regression fixed by 166bf8af9122 ("pinctrl: mediatek: common-v2: Fix broken bias-disable for PULL_PU_PD_RSEL_TYPE"). A bug was introduced in the pinctrl_paris driver which prevented certain pins from having their bias configured. Running this test on the mt8195-tomato platform with the test plan included below[1] shows the test passing with the fix applied, but failing without the fix: With fix: $ ./gpio-setget-config.py TAP version 13 # Using test plan file: ./google,tomato.yaml 1..3 ok 1 pinctrl_paris.34.pull-up ok 2 pinctrl_paris.34.pull-down ok 3 pinctrl_paris.34.disabled # Totals: pass:3 fail:0 xfail:0 xpass:0 skip:0 error:0 Without fix: $ ./gpio-setget-config.py TAP version 13 # Using test plan file: ./google,tomato.yaml 1..3 # Bias doesn't match: Expected pull-up, read pull-down. not ok 1 pinctrl_paris.34.pull-up ok 2 pinctrl_paris.34.pull-down # Bias doesn't match: Expected disabled, read pull-down. not ok 3 pinctrl_paris.34.disabled # Totals: pass:1 fail:2 xfail:0 xpass:0 skip:0 error:0 In order to achieve this, the first three patches expose bias configuration through the GPIO API in the MediaTek pinctrl drivers, notably, pinctrl_paris, patch 4 extends the gpio-mockup-cdev utility for use by patch 5, and patch 5 introduces a new GPIO kselftest that takes a test plan in YAML, which can be tailored per-platform to specify the configurations to test, and sets and gets back each pin configuration to verify that they match and thus that the driver is behaving as expected. Since the GPIO uAPI only allows setting the pin configuration, getting it back is done through pinconf-pins in the pinctrl debugfs folder. The test currently only verifies bias but it would be easy to extend to verify other pin configurations. The test plan YAML file can be customized for each use-case and is platform-dependant. For that reason, only an example is included in patch 3 and the user is supposed to provide their test plan. That said, the aim is to collect test plans for ease of use at [2]. [1] This is the test plan used for mt8195-tomato: - label: "pinctrl_paris" tests: # Pin 34 has type MTK_PULL_PU_PD_RSEL_TYPE and is unused. # Setting bias to MTK_PULL_PU_PD_RSEL_TYPE pins was fixed by # 166bf8af9122 ("pinctrl: mediatek: common-v2: Fix broken bias-disable for PULL_PU_PD_RSEL_TYPE") - pin: 34 bias: "pull-up" - pin: 34 bias: "pull-down" - pin: 34 bias: "disabled" [2] https://github.com/kernelci/platform-test-parameters Signed-off-by: Nícolas F. R. A. Prado <nfraprado(a)collabora.com> --- Changes in v2: - Added patches 2 and 3 enabling the extra GPIO pin configurations on the other mediatek drivers: pinctrl-moore and pinctrl-mtk-common - Tweaked function name in patch 1: mtk_pinconf_set -> mtk_paris_pin_config_set, to make it clear it is not a pinconf_ops - Adjusted commit message to make it clear the current support is limited to pins supported by the EINT controller - Link to v1: https://lore.kernel.org/r/20240909-kselftest-gpio-set-get-config-v1-0-16a06… --- Nícolas F. R. A. Prado (5): pinctrl: mediatek: paris: Expose more configurations to GPIO set_config pinctrl: mediatek: moore: Expose more configurations to GPIO set_config pinctrl: mediatek: common: Expose more configurations to GPIO set_config selftest: gpio: Add wait flag to gpio-mockup-cdev selftest: gpio: Add a new set-get config test drivers/pinctrl/mediatek/pinctrl-moore.c | 283 +++++++++++---------- drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 48 ++-- drivers/pinctrl/mediatek/pinctrl-paris.c | 26 +- tools/testing/selftests/gpio/Makefile | 2 +- tools/testing/selftests/gpio/gpio-mockup-cdev.c | 14 +- .../gpio-set-get-config-example-test-plan.yaml | 15 ++ .../testing/selftests/gpio/gpio-set-get-config.py | 183 +++++++++++++ 7 files changed, 395 insertions(+), 176 deletions(-) --- base-commit: a39230ecf6b3057f5897bc4744a790070cfbe7a8 change-id: 20240906-kselftest-gpio-set-get-config-6e5bb670c1a5 Best regards, -- Nícolas F. R. A. Prado <nfraprado(a)collabora.com>

9 months, 3 weeks

3
12
0 0

[PATCH v3 0/3] rust: kunit: Support KUnit tests with a user-space like syntax

by David Gow

This series was originally written by José Expósito, and has been modified and updated by Matt Gilbride and myself. The original version can be found here: https://github.com/Rust-for-Linux/linux/pull/950 Add support for writing KUnit tests in Rust. While Rust doctests are already converted to KUnit tests and run, they're really better suited for examples, rather than as first-class unit tests. This series implements a series of direct Rust bindings for KUnit tests, as well as a new macro which allows KUnit tests to be written using a close variant of normal Rust unit test syntax. The only change required is replacing '#[cfg(test)]' with '#[kunit_tests(kunit_test_suite_name)]' An example test would look like: #[kunit_tests(rust_kernel_hid_driver)] mod tests { use super::*; use crate::{c_str, driver, hid, prelude::*}; use core::ptr; struct SimpleTestDriver; impl Driver for SimpleTestDriver { type Data = (); } #[test] fn rust_test_hid_driver_adapter() { let mut hid = bindings::hid_driver::default(); let name = c_str!("SimpleTestDriver"); static MODULE: ThisModule = unsafe { ThisModule::from_ptr(ptr::null_mut()) }; let res = unsafe { <hid::Adapter<SimpleTestDriver> as driver::DriverOps>::register(&mut hid, name, &MODULE) }; assert_eq!(res, Err(ENODEV)); // The mock returns -19 } } Please give this a go, and make sure I haven't broken it! There's almost certainly a lot of improvements which can be made -- and there's a fair case to be made for replacing some of this with generated C code which can use the C macros -- but this is hopefully an adequate implementation for now, and the interface can (with luck) remain the same even if the implementation changes. A few small notable missing features: - Attributes (like the speed of a test) are hardcoded to the default value. - Similarly, the module name attribute is hardcoded to NULL. In C, we use the KBUILD_MODNAME macro, but I couldn't find a way to use this from Rust which wasn't more ugly than just disabling it. - Assertions are not automatically rewritten to use KUnit assertions. --- Changes since v2: https://lore.kernel.org/linux-kselftest/20241029092422.2884505-1-davidgow@g… - Include missing rust/macros/kunit.rs file from v2. (Thanks Boqun!) - The kunit_unsafe_test_suite!() macro will truncate the name of the suite if it is too long. (Thanks Alice!) - The proc macro now emits an error if the suite name is too long. - We no longer needlessly use UnsafeCell<> in kunit_unsafe_test_suite!(). (Thanks Alice!) Changes since v1: https://lore.kernel.org/lkml/20230720-rustbind-v1-0-c80db349e3b5@google.com… - Rebase on top of the latest rust-next (commit 718c4069896c) - Make kunit_case a const fn, rather than a macro (Thanks Boqun) - As a result, the null terminator is now created with kernel::kunit::kunit_case_null() - Use the C kunit_get_current_test() function to implement in_kunit_test(), rather than re-implementing it (less efficiently) ourselves. Changes since the GitHub PR: - Rebased on top of kselftest/kunit - Add const_mut_refs feature This may conflict with https://lore.kernel.org/lkml/20230503090708.2524310-6-nmi@metaspace.dk/ - Add rust/macros/kunit.rs to the KUnit MAINTAINERS entry --- José Expósito (3): rust: kunit: add KUnit case and suite macros rust: macros: add macro to easily run KUnit tests rust: kunit: allow to know if we are in a test MAINTAINERS | 1 + rust/kernel/kunit.rs | 191 +++++++++++++++++++++++++++++++++++++++++++ rust/kernel/lib.rs | 1 + rust/macros/kunit.rs | 153 ++++++++++++++++++++++++++++++++++ rust/macros/lib.rs | 29 +++++++ 5 files changed, 375 insertions(+) create mode 100644 rust/macros/kunit.rs -- 2.47.0.163.g1226f6d8fa-goog

9 months, 3 weeks

2
6
0 0

[PATCH net-next] selftests: netdevsim: add fib_notifications to Makefile

by Jakub Kicinski

Commit 19d36d2971e6 ("selftests: netdevsim: Add fib_notifications test") added the test but didn't include it in the Makefile. Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> --- CC: andrew+netdev(a)lunn.ch CC: shuah(a)kernel.org CC: linux-kselftest(a)vger.kernel.org CC: petrm(a)nvidia.com --- tools/testing/selftests/drivers/net/netdevsim/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/testing/selftests/drivers/net/netdevsim/Makefile b/tools/testing/selftests/drivers/net/netdevsim/Makefile index 5bace0b7fb57..cc08b220323f 100644 --- a/tools/testing/selftests/drivers/net/netdevsim/Makefile +++ b/tools/testing/selftests/drivers/net/netdevsim/Makefile @@ -8,6 +8,7 @@ TEST_PROGS = devlink.sh \ ethtool-pause.sh \ ethtool-ring.sh \ fib.sh \ + fib_notifications.sh \ hw_stats_l3.sh \ nexthop.sh \ peer.sh \ -- 2.47.0

9 months, 3 weeks

3
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror October 2024