Linux-kselftest-mirror

linux-kselftest-mirror@lists.linaro.org

105 participants
14257 discussions

[RFC bpf PATCH 0/2] bpf: Fix memory access tags in helper prototypes

by Zesen Liu

Hi, This series adds missing memory access tags (MEM_RDONLY or MEM_WRITE) to several bpf helper function prototypes that use ARG_PTR_TO_MEM but lack the correct type annotation. Missing memory access tags in helper prototypes can lead to critical correctness issues when the verifier tries to perform code optimization. After commit 37cce22dbd51 ("bpf: verifier: Refactor helper access type tracking"), the verifier relies on the memory access tags, rather than treating all arguments in helper functions as potentially modifying the pointed-to memory. We have already seen several reports regarding this: - commit ac44dcc788b9 ("bpf: Fix verifier assumptions of bpf_d_path's output buffer") adds MEM_WRITE to bpf_d_path; - commit 2eb7648558a7 ("bpf: Specify access type of bpf_sysctl_get_name args") adds MEM_WRITE to bpf_sysctl_get_name. This series looks through all prototypes in the kernel and completes the tags. In addition, this series also adds selftests for some of these functions. I marked the series as RFC since the introduced selftests are fragile and ad hoc (similar to the previously added selftests). The original goal of these tests is to reproduce the case where the verifier wrongly optimizes reads after the helper function is called. However, triggering the error often requires carefully designed code patterns. For example, I had to explicitly use "if (xx != 0)" in my attached tests, because using memcmp will not reproduce the issue. This makes the reproduction heavily dependent on the verifier's internal optimization logic and clutters the selftests with specific, unnatural patterns. Some cases are also hard to trigger by selftests. For example, I couldn't find a triggering pattern for bpf_read_branch_records, since the execution of program seems to be messed up by wrong tags. For bpf_skb_fib_lookup, I also failed to reproduce it because the argument needs content on entry, but the verifier seems to only enable this optimization for fully empty buffers. Since adding selftests does not help with existing issues or prevent future occurrences of similar problems, I believe one way to resolve it is to statically restrict ARG_PTR_TO_MEM from appearing without memory access tags. Using ARG_PTR_TO_MEM alone without tags is nonsensical because: - If the helper does not change the argument, missing MEM_RDONLY causes the verifier to incorrectly reject a read-only buffer. - If the helper does change the argument, missing MEM_WRITE causes the verifier to incorrectly assume the memory is unchanged, leading to potential errors. I am still wondering, if we agree on the above, how should we enforce this restriction? Should we let ARG_PTR_TO_MEM imply MEM_WRITE semantics by default, and change ARG_PTR_TO_MEM | MEM_RDONLY to ARG_CONST_PTR_TO_MEM? Or should we add a check in the verifier to ensure ARG_PTR_TO_MEM always comes with an access tag (though this seems to only catch errors at runtime/testing)? Any insights and comments are welcome. If the individual fix patches for the prototypes look correct, I would also really appreciate it if they could be merged ahead of the discussion. Thanks, Zesen Liu Signed-off-by: Zesen Liu <ftyghome(a)gmail.com> --- Zesen Liu (2): bpf: Fix memory access tags in helper prototypes selftests/bpf: add regression tests for snprintf and get_stack helpers kernel/bpf/helpers.c | 2 +- kernel/trace/bpf_trace.c | 6 +++--- net/core/filter.c | 8 ++++---- tools/testing/selftests/bpf/prog_tests/get_stack_raw_tp.c | 15 +++++++++++++-- tools/testing/selftests/bpf/prog_tests/snprintf.c | 6 ++++++ tools/testing/selftests/bpf/prog_tests/snprintf_btf.c | 3 +++ tools/testing/selftests/bpf/progs/netif_receive_skb.c | 13 ++++++++++++- tools/testing/selftests/bpf/progs/test_get_stack_rawtp.c | 11 ++++++++++- tools/testing/selftests/bpf/progs/test_snprintf.c | 12 ++++++++++++ 9 files changed, 64 insertions(+), 12 deletions(-) --- base-commit: 22cc16c04b7893d8fc22810599f49a305d600b9e change-id: 20251220-helper_proto-fb6e64182467 Best regards, -- Zesen Liu <ftyghome(a)gmail.com>

2 weeks, 3 days

[PATCH v2 1/5] selftests/mm: fix va_high_addr_switch.sh return value

by Chunyu Hu

Patch series "Fix va_high_addr_switch.sh test failure - again", v2. The series address several issues exist for the va_high_addr_switch test: 1) the test return value is ignored in va_high_addr_switch.sh. 2) the va_high_addr_switch test requires 6 hugepages not 5. 3) the reurn value of the first test in va_high_addr_switch.c can be overridden by the second test. 4) the nr_hugepages setup in run_vmtests.sh for arm64 can be done in va_high_addr_switch.sh too. 5) update a comment for check_test_requirements. Changes in v2: - shorten the comment in for hugepages setup in v1 - add a new patch to fix the return value overridden issue in va_high_addr_switch.c - fix a code comment for check_test_requirements. - update the series summary in patch 1 - add reviewed-by from Luiz Capitulino on patch 1 and patch 3 This patch: (of 5) The return value should be return value of va_high_addr_switch, otherwise a test failure would be silently ignored. Reviewed-by: Luiz Capitulino <luizcap(a)redhat.com> Fixes: d9d957bd7b61 ("selftests/mm: alloc hugepages in va_high_addr_switch test") CC: Luiz Capitulino <luizcap(a)redhat.com> Signed-off-by: Chunyu Hu <chuhu(a)redhat.com> --- Chunyu Hu (5): selftests/mm: fix va_high_addr_switch.sh return value selftests/mm: allocate 6 hugepages in va_high_addr_switch.sh selftests/mm: remove arm64 nr_hugepages setup for va_high_addr_switch test selftests/mm: va_high_addr_switch return fail when either test failed selftests/mm: fix comment for check_test_requirements tools/testing/selftests/mm/run_vmtests.sh | 8 -------- tools/testing/selftests/mm/va_high_addr_switch.c | 10 +++++++--- tools/testing/selftests/mm/va_high_addr_switch.sh | 12 +++++++----- 3 files changed, 14 insertions(+), 16 deletions(-) According to the doc below, I don't add the cover letter, not sure if cover letter is preferred, and if that's the case, the doc need an update. https://www.ozlabs.org/~akpm/stuff/tpp.txt --- tools/testing/selftests/mm/va_high_addr_switch.sh | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/testing/selftests/mm/va_high_addr_switch.sh b/tools/testing/selftests/mm/va_high_addr_switch.sh index a7d4b02b21dd..f89fe078a8e6 100755 --- a/tools/testing/selftests/mm/va_high_addr_switch.sh +++ b/tools/testing/selftests/mm/va_high_addr_switch.sh @@ -114,4 +114,6 @@ save_nr_hugepages # 4 keep_mapped pages, and one for tmp usage setup_nr_hugepages 5 ./va_high_addr_switch --run-hugetlb +retcode=$? restore_nr_hugepages +exit $retcode -- 2.49.0

2 weeks, 3 days

[PATCH] selftests/hid: run vmtest.sh's pytest with verbose output

by Peter Hutterer

This way we see in the log output which tests were run and which ones were skipped instead of just `....sss.ss..`. Signed-off-by: Peter Hutterer <peter.hutterer(a)who-t.net> --- tools/testing/selftests/hid/vmtest.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/hid/vmtest.sh b/tools/testing/selftests/hid/vmtest.sh index ecbd57f775a0..fc21fb495a8a 100755 --- a/tools/testing/selftests/hid/vmtest.sh +++ b/tools/testing/selftests/hid/vmtest.sh @@ -349,7 +349,7 @@ test_vm_pytest() { shift - vm_ssh -- pytest ${SCRIPT_DIR}/tests --color=yes "$@" \ + vm_ssh -- pytest ${SCRIPT_DIR}/tests -v --color=yes "$@" \ 2>&1 | log_guest "${testname}" return ${PIPESTATUS[0]} -- 2.51.1

2 weeks, 3 days

[PATCH v2] kunit: Enforce task execution in {soft,hard}irq contexts

by David Gow

The kunit_run_irq_test() helper allows a function to be run in hardirq and softirq contexts (in addition to the task context). It does this by running the user-provided function concurrently in the three contexts, until either a timeout has expired or a number of iterations have completed in the normal task context. However, on setups where the initialisation of the hardirq and softirq contexts (or, indeed, the scheduling of those tasks) is significantly slower than the function execution, it's possible for that number of iterations to be exceeded before any runs in irq contexts actually occur. This occurs with the polyval.test_polyval_preparekey_in_irqs test, which runs 20000 iterations of the relatively fast preparekey function, and therefore fails often under many UML, 32-bit arm, m68k and other environments. Instead, ensure that the max_iterations limit counts executions in all three contexts, and requires at least one of each. This will cause the test to continue iterating until at least the irq contexts have been tested, or the 1s wall-clock limit has been exceeded. This causes the test to pass in all of my environments. In so doing, we also update the task counters to atomic ints, to better match both the 'int' max_iterations input, and to ensure they are correctly updated across contexts. Finally, we also fix a few potential assertion messages to be less-specific to the original crypto usecases. Fixes: b41dc83f0790 ("kunit, lib/crypto: Move run_irq_test() to common header") Signed-off-by: David Gow <davidgow(a)google.com> --- Changes since v1: https://lore.kernel.org/all/20251219080850.921416-1-davidgow@google.com/ - Remove a leftover debug line which forced max_iterations to 1. include/kunit/run-in-irq-context.h | 39 ++++++++++++++++++++---------- 1 file changed, 26 insertions(+), 13 deletions(-) diff --git a/include/kunit/run-in-irq-context.h b/include/kunit/run-in-irq-context.h index 108e96433ea4..84694f383e37 100644 --- a/include/kunit/run-in-irq-context.h +++ b/include/kunit/run-in-irq-context.h @@ -20,8 +20,8 @@ struct kunit_irq_test_state { bool task_func_reported_failure; bool hardirq_func_reported_failure; bool softirq_func_reported_failure; - unsigned long hardirq_func_calls; - unsigned long softirq_func_calls; + atomic_t hardirq_func_calls; + atomic_t softirq_func_calls; struct hrtimer timer; struct work_struct bh_work; }; @@ -32,7 +32,7 @@ static enum hrtimer_restart kunit_irq_test_timer_func(struct hrtimer *timer) container_of(timer, typeof(*state), timer); WARN_ON_ONCE(!in_hardirq()); - state->hardirq_func_calls++; + atomic_inc(&state->hardirq_func_calls); if (!state->func(state->test_specific_state)) state->hardirq_func_reported_failure = true; @@ -48,7 +48,7 @@ static void kunit_irq_test_bh_work_func(struct work_struct *work) container_of(work, typeof(*state), bh_work); WARN_ON_ONCE(!in_serving_softirq()); - state->softirq_func_calls++; + atomic_inc(&state->softirq_func_calls); if (!state->func(state->test_specific_state)) state->softirq_func_reported_failure = true; @@ -59,7 +59,10 @@ static void kunit_irq_test_bh_work_func(struct work_struct *work) * hardirq context concurrently, and reports a failure to KUnit if any * invocation of @func in any context returns false. @func is passed * @test_specific_state as its argument. At most 3 invocations of @func will - * run concurrently: one in each of task, softirq, and hardirq context. + * run concurrently: one in each of task, softirq, and hardirq context. @func + * will continue running until either @max_iterations calls have been made (so + * long as at least one each runs in task, softirq, and hardirq contexts), or + * one second has passed. * * The main purpose of this interrupt context testing is to validate fallback * code paths that run in contexts where the normal code path cannot be used, @@ -85,6 +88,8 @@ static inline void kunit_run_irq_test(struct kunit *test, bool (*func)(void *), .test_specific_state = test_specific_state, }; unsigned long end_jiffies; + int hardirq_calls, softirq_calls; + bool allctx = false; /* * Set up a hrtimer (the way we access hardirq context) and a work @@ -94,14 +99,22 @@ static inline void kunit_run_irq_test(struct kunit *test, bool (*func)(void *), CLOCK_MONOTONIC, HRTIMER_MODE_REL_HARD); INIT_WORK_ONSTACK(&state.bh_work, kunit_irq_test_bh_work_func); - /* Run for up to max_iterations or 1 second, whichever comes first. */ + /* Run for up to max_iterations (including at least one task, softirq, + * and hardirq), or 1 second, whichever comes first. + */ end_jiffies = jiffies + HZ; hrtimer_start(&state.timer, KUNIT_IRQ_TEST_HRTIMER_INTERVAL, HRTIMER_MODE_REL_HARD); - for (int i = 0; i < max_iterations && !time_after(jiffies, end_jiffies); - i++) { + for (int task_calls = 0, calls = 0; + ((calls < max_iterations) || !allctx) && !time_after(jiffies, end_jiffies); + task_calls++) { if (!func(test_specific_state)) state.task_func_reported_failure = true; + + hardirq_calls = atomic_read(&state.hardirq_func_calls); + softirq_calls = atomic_read(&state.softirq_func_calls); + calls = task_calls + hardirq_calls + softirq_calls; + allctx = (task_calls > 0) && (hardirq_calls > 0) && (softirq_calls > 0); } /* Cancel the timer and work. */ @@ -109,21 +122,21 @@ static inline void kunit_run_irq_test(struct kunit *test, bool (*func)(void *), flush_work(&state.bh_work); /* Sanity check: the timer and BH functions should have been run. */ - KUNIT_EXPECT_GT_MSG(test, state.hardirq_func_calls, 0, + KUNIT_EXPECT_GT_MSG(test, atomic_read(&state.hardirq_func_calls), 0, "Timer function was not called"); - KUNIT_EXPECT_GT_MSG(test, state.softirq_func_calls, 0, + KUNIT_EXPECT_GT_MSG(test, atomic_read(&state.softirq_func_calls), 0, "BH work function was not called"); /* Check for incorrect hash values reported from any context. */ KUNIT_EXPECT_FALSE_MSG( test, state.task_func_reported_failure, - "Incorrect hash values reported from task context"); + "Failure reported from task context"); KUNIT_EXPECT_FALSE_MSG( test, state.hardirq_func_reported_failure, - "Incorrect hash values reported from hardirq context"); + "Failure reported from hardirq context"); KUNIT_EXPECT_FALSE_MSG( test, state.softirq_func_reported_failure, - "Incorrect hash values reported from softirq context"); + "Failure reported from softirq context"); } #endif /* _KUNIT_RUN_IN_IRQ_CONTEXT_H */ -- 2.52.0.322.g1dd061c0dc-goog

2 weeks, 3 days

[PATCH v2 00/19] rust: replace `kernel::c_str!` with C-Strings

by Tamir Duberstein

This series depends on step 3[0]. Subsystem maintainers: I would appreciate your `Acked-by`s so that this can be taken through Miguel's tree (where the previous series must go). Link: https://lore.kernel.org/all/20250925-cstr-core-v16-0-5cdcb3470ec2@gmail.com/ [0] Signed-off-by: Tamir Duberstein <tamird(a)gmail.com> --- Changes in v2: - Rebase. - Add two patches to address new code. - Drop incorrectly applied Acked-by tags from Danilo. - Link to v1: https://lore.kernel.org/r/20250710-core-cstr-cstrings-v1-0-027420ea799e@gma… --- Tamir Duberstein (19): drivers: net: replace `kernel::c_str!` with C-Strings gpu: nova-core: replace `kernel::c_str!` with C-Strings rust: auxiliary: replace `kernel::c_str!` with C-Strings rust: clk: replace `kernel::c_str!` with C-Strings rust: configfs: replace `kernel::c_str!` with C-Strings rust: cpufreq: replace `kernel::c_str!` with C-Strings rust: device: replace `kernel::c_str!` with C-Strings rust: firmware: replace `kernel::c_str!` with C-Strings rust: kunit: replace `kernel::c_str!` with C-Strings rust: macros: replace `kernel::c_str!` with C-Strings rust: miscdevice: replace `kernel::c_str!` with C-Strings rust: net: replace `kernel::c_str!` with C-Strings rust: pci: replace `kernel::c_str!` with C-Strings rust: platform: replace `kernel::c_str!` with C-Strings rust: seq_file: replace `kernel::c_str!` with C-Strings rust: str: replace `kernel::c_str!` with C-Strings rust: sync: replace `kernel::c_str!` with C-Strings rust: io: replace `kernel::c_str!` with C-Strings rust: regulator: replace `kernel::c_str!` with C-Strings drivers/block/rnull.rs | 2 +- drivers/cpufreq/rcpufreq_dt.rs | 5 ++--- drivers/gpu/drm/nova/driver.rs | 10 +++++----- drivers/gpu/nova-core/driver.rs | 6 +++--- drivers/net/phy/ax88796b_rust.rs | 7 +++---- drivers/net/phy/qt2025.rs | 5 ++--- rust/kernel/clk.rs | 6 ++---- rust/kernel/configfs.rs | 9 +++++---- rust/kernel/cpufreq.rs | 3 +-- rust/kernel/device.rs | 4 +--- rust/kernel/device/property.rs | 6 +++--- rust/kernel/firmware.rs | 6 +++--- rust/kernel/io/mem.rs | 7 +++---- rust/kernel/kunit.rs | 11 ++++------- rust/kernel/net/phy.rs | 6 ++---- rust/kernel/platform.rs | 6 +++--- rust/kernel/regulator.rs | 9 +++------ rust/kernel/seq_file.rs | 4 ++-- rust/kernel/str.rs | 5 ++--- rust/kernel/sync.rs | 5 ++--- rust/kernel/sync/completion.rs | 2 +- rust/kernel/workqueue.rs | 8 ++++---- rust/macros/kunit.rs | 10 +++++----- rust/macros/module.rs | 2 +- samples/rust/rust_configfs.rs | 5 ++--- samples/rust/rust_driver_auxiliary.rs | 4 ++-- samples/rust/rust_driver_faux.rs | 4 ++-- samples/rust/rust_driver_pci.rs | 4 ++-- samples/rust/rust_driver_platform.rs | 30 ++++++++++++++---------------- samples/rust/rust_misc_device.rs | 3 +-- scripts/rustdoc_test_gen.rs | 4 ++-- 31 files changed, 88 insertions(+), 110 deletions(-) --- base-commit: f3f6b3664302e16ef1c6b91034a72df5564d6b8a change-id: 20250710-core-cstr-cstrings-1faaa632f0fd prerequisite-change-id: 20250201-cstr-core-d4b9b69120cf:v16 prerequisite-patch-id: e0ca756f740ab0ce7478bbf6510948ba89529a2f prerequisite-patch-id: 6d8dbdf864f79fc0c2820e702a7cb87753649ca0 prerequisite-patch-id: 7d4d1d036043a85dcbaf0d09ea85768120efe094 Best regards, -- Tamir Duberstein <tamird(a)gmail.com>

2 weeks, 3 days

[PATCH v3 0/3] selftests/mm: hugetlb cgroup charging: robustness fixes

by Li Wang

Changes in v3: - 1/3: no changes. - 2/3: reorder with 3/3, and drop the 'size=' mount args. - 3/3: add $path check, improve varible declaration, sleep 1s for 60 tryies. Changes in v2: - 1/3: Parse -s using sscanf("%zu", ...) instead of strtoull(). - 2/3: Fix typo in charge_reserved_hugetlb.sh ("reseravation" -> "reservation"). - 3/3: No changes. This series fixes a few issues in the hugetlb cgroup charging selftests (write_to_hugetlbfs.c + charge_reserved_hugetlb.sh) that show up on systems with large hugepages (e.g. 512MB) and when failures cause the test to wait indefinitely. On an aarch64 64k page kernel with 512MB hugepages, the test consistently fails in write_to_hugetlbfs with ENOMEM and then hangs waiting for the expected usage values. The root cause is that charge_reserved_hugetlb.sh mounts hugetlbfs with a fixed size=256M, which is smaller than a single hugepage, resulting in a mount with size=0 capacity. In addition, write_to_hugetlbfs previously parsed -s via atoi() into an int, which can overflow and print negative sizes. Reproducer / environment: - Kernel: 6.12.0-xxx.el10.aarch64+64k - Hugepagesize: 524288 kB (512MB) - ./charge_reserved_hugetlb.sh -cgroup-v2 - Observed mount: pagesize=512M,size=0 before this series After applying the series, the test completes successfully on the above setup. Li Wang (3): selftests/mm/write_to_hugetlbfs: parse -s as size_t selftests/mm/charge_reserved_hugetlb: drop mount size for hugetlbfs selftests/mm/charge_reserved_hugetlb.sh: add waits with timeout helper .../selftests/mm/charge_reserved_hugetlb.sh | 55 +++++++++++-------- .../testing/selftests/mm/write_to_hugetlbfs.c | 9 ++- 2 files changed, 38 insertions(+), 26 deletions(-) -- 2.49.0

2 weeks, 3 days

[PATCH v2] KVM: selftests: Fix sign extension bug in get_desc64_base()

by MJ Pooladkhay

The function get_desc64_base() performs a series of bitwise left shifts on fields of various sizes. More specifically, when performing '<< 24' on 'desc->base2' (which is a u8), 'base2' is promoted to a signed integer before shifting. In a scenario where base2 >= 0x80, the shift places a 1 into bit 31, causing the 32-bit intermediate value to become negative. When this result is cast to uint64_t or ORed into the return value, sign extension occurs, corrupting the upper 32 bits of the address (base3). Example: Given: base0 = 0x5000 base1 = 0xd6 base2 = 0xf8 base3 = 0xfffffe7c Expected return: 0xfffffe7cf8d65000 Actual return: 0xfffffffff8d65000 Fix this by explicitly casting the fields to 'uint64_t' before shifting to prevent sign extension. Signed-off-by: MJ Pooladkhay <mj(a)pooladkhay.com> --- v2: - Remove the intermediate 'low' variable and use a single return statement as suggested by Sean Christopherson. v1: https://lore.kernel.org/kvm/20251220021050.88490-1-mj@pooladkhay.com/ While using get_desc64_base() to set the HOST_TR_BASE value for a custom educational hypervisor, I observed system freezes, either immediately or after migrating the guest to a new core. I eventually realized that KVM uses get_cpu_entry_area() for the TR base. Switching to that fixed my freezes (which were triple faults on one core followed by soft lockups on others, waiting on smp_call_function_many_cond) and helped me identify the sign-extension bug in this helper function that was corrupting the HOST_TR_BASE value. Thanks, MJ Pooladkhay tools/testing/selftests/kvm/include/x86/processor.h | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/kvm/include/x86/processor.h b/tools/testing/selftests/kvm/include/x86/processor.h index 57d62a425..26a91bb73 100644 --- a/tools/testing/selftests/kvm/include/x86/processor.h +++ b/tools/testing/selftests/kvm/include/x86/processor.h @@ -436,8 +436,10 @@ struct kvm_x86_state { static inline uint64_t get_desc64_base(const struct desc64 *desc) { - return ((uint64_t)desc->base3 << 32) | - (desc->base0 | ((desc->base1) << 16) | ((desc->base2) << 24)); + return (uint64_t)desc->base3 << 32 | + (uint64_t)desc->base2 << 24 | + (uint64_t)desc->base1 << 16 | + (uint64_t)desc->base0; } static inline uint64_t rdtsc(void) -- 2.52.0

2 weeks, 3 days

[PATCH] KVM: selftests: Fix sign extension bug in get_desc64_base()

by MJ Pooladkhay

The function get_desc64_base() performs a series of bitwise left shifts on fields of various sizes. More specifically, when performing '<< 24' on 'desc->base2' (which is a u8), 'base2' is promoted to a signed integer before shifting. In a scenario where base2 >= 0x80, the shift places a 1 into bit 31, causing the 32-bit intermediate value to become negative. When this result is cast to uint64_t or ORed into the return value, sign extension occurs, corrupting the upper 32 bits of the address (base3). Example: Given: base0 = 0x5000 base1 = 0xd6 base2 = 0xf8 base3 = 0xfffffe7c Expected return: 0xfffffe7cf8d65000 Actual return: 0xfffffffff8d65000 Fix this by explicitly casting the fields to 'uint64_t' before shifting to prevent sign extension. Signed-off-by: MJ Pooladkhay <mj(a)pooladkhay.com> --- While using get_desc64_base() to set the HOST_TR_BASE value for a custom educational hypervisor, I observed system freezes, either immediately or after migrating the guest to a new core. I eventually realized that KVM uses get_cpu_entry_area() for the TR base. Switching to that fixed my freezes (which were triple faults on one core followed by soft lockups on others, waiting on smp_call_function_many_cond) and helped me identify the sign-extension bug in this helper function that was corrupting the HOST_TR_BASE value. Thanks, MJ Pooladkhay tools/testing/selftests/kvm/include/x86/processor.h | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/kvm/include/x86/processor.h b/tools/testing/selftests/kvm/include/x86/processor.h index 57d62a425..cc2f8fb6f 100644 --- a/tools/testing/selftests/kvm/include/x86/processor.h +++ b/tools/testing/selftests/kvm/include/x86/processor.h @@ -436,8 +436,11 @@ struct kvm_x86_state { static inline uint64_t get_desc64_base(const struct desc64 *desc) { - return ((uint64_t)desc->base3 << 32) | - (desc->base0 | ((desc->base1) << 16) | ((desc->base2) << 24)); + uint64_t low = (uint64_t)desc->base0 | + ((uint64_t)desc->base1 << 16) | + ((uint64_t)desc->base2 << 24); + + return (uint64_t)desc->base3 << 32 | low; } static inline uint64_t rdtsc(void) -- 2.52.0

2 weeks, 3 days

[PATCH v3 00/14] tools/nolibc: always use 64-bit time-related types

by Thomas Weißschuh

nolibc currently uses 32-bit types for various APIs. These are problematic as their reduced value range can lead to truncated values. Intended for 6.19. Signed-off-by: Thomas Weißschuh <linux(a)weissschuh.net> --- Changes in v3: - Only use _Static_assert() where available - Link to v2: https://lore.kernel.org/r/20251122-nolibc-uapi-types-v2-0-b814a43654f5@weis… Changes in v2: - Drop already applied ino_t and off_t patches. - Also handle 'struct timeval'. - Make the progression of the series a bit clearer. - Add compatibility assertions. - Link to v1: https://lore.kernel.org/r/20251029-nolibc-uapi-types-v1-0-e79de3b215d8@weis… --- Thomas Weißschuh (14): tools/nolibc/poll: use kernel types for system call invocations tools/nolibc/poll: drop __NR_poll fallback tools/nolibc/select: drop non-pselect based implementations tools/nolibc/time: drop invocation of gettimeofday system call tools/nolibc: prefer explicit 64-bit time-related system calls tools/nolibc/gettimeofday: avoid libgcc 64-bit divisions tools/nolibc/select: avoid libgcc 64-bit multiplications tools/nolibc: use custom structs timespec and timeval tools/nolibc: always use 64-bit time types selftests/nolibc: test compatibility of nolibc and kernel time types tools/nolibc: remove time conversions tools/nolibc: add compiler version detection macros tools/nolibc: add __nolibc_static_assert() selftests/nolibc: add static assertions around time types handling tools/include/nolibc/arch-s390.h | 3 + tools/include/nolibc/compiler.h | 24 +++++++ tools/include/nolibc/poll.h | 14 ++-- tools/include/nolibc/std.h | 2 +- tools/include/nolibc/sys/select.h | 25 ++----- tools/include/nolibc/sys/time.h | 6 +- tools/include/nolibc/sys/timerfd.h | 32 +++------ tools/include/nolibc/time.h | 102 +++++++++------------------ tools/include/nolibc/types.h | 17 ++++- tools/testing/selftests/nolibc/nolibc-test.c | 27 +++++++ 10 files changed, 129 insertions(+), 123 deletions(-) --- base-commit: 351ec197a66e47bea17c3d803c5472473640dd0d change-id: 20251001-nolibc-uapi-types-1c072d10fcc7 Best regards, -- Thomas Weißschuh <linux(a)weissschuh.net>

2 weeks, 4 days

[PATCH] selftests: net: fib-onlink-tests: Set high metric for default IPv6 route

by Ricardo B. Marlière

Currently, the test breaks if the SUT already has a default route configured for IPv6. Fix by adding "metric 9999" to the `ip -6 ro add` command, so that multiple default routes can coexist. Fixes: 4ed591c8ab44 ("net/ipv6: Allow onlink routes to have a device mismatch if it is the default route") Signed-off-by: Ricardo B. Marlière <rbm(a)suse.com> --- tools/testing/selftests/net/fib-onlink-tests.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/net/fib-onlink-tests.sh b/tools/testing/selftests/net/fib-onlink-tests.sh index ec2d6ceb1f08..acf6b0617373 100755 --- a/tools/testing/selftests/net/fib-onlink-tests.sh +++ b/tools/testing/selftests/net/fib-onlink-tests.sh @@ -207,7 +207,7 @@ setup() ip -netns ${PEER_NS} addr add ${V6ADDRS[p${n}]}/64 dev ${NETIFS[p${n}]} nodad done - ip -6 ro add default via ${V6ADDRS[p3]/::[0-9]/::64} + ip -6 ro add default via ${V6ADDRS[p3]/::[0-9]/::64} metric 9999 ip -6 ro add table ${VRF_TABLE} default via ${V6ADDRS[p7]/::[0-9]/::64} set +e --- base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8 change-id: 20251218-rbm-selftests-net-fib-onlink-873ad01e6884 Best regards, -- Ricardo B. Marlière <rbm(a)suse.com>

2 weeks, 4 days

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror