kernel/linux.git/tools, branch v6.12.53

nvdimm: ndtest: Return -ENOMEM if devm_kcalloc() fails in ndtest_probe()

2025-10-15T10:00:23+00:00

commit a9e6aa994917ee602798bbb03180a194b37865bb upstream. devm_kcalloc() may fail. ndtest_probe() allocates three DMA address arrays (dcr_dma, label_dma, dimm_dma) and later unconditionally uses them in ndtest_nvdimm_init(), which can lead to a NULL pointer dereference under low-memory conditions. Check all three allocations and return -ENOMEM if any allocation fails, jumping to the common error path. Do not emit an extra error message since the allocator already warns on allocation failure. Fixes: 9399ab61ad82 ("ndtest: Add dimms to the two buses") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Reviewed-by: Alison Schofield Reviewed-by: Ira Weiny Reviewed-by: Dave Jiang Signed-off-by: Ira Weiny Signed-off-by: Greg Kroah-Hartman

libbpf: Fix error when st-prefix_ops and ops from differ btf

2025-10-15T10:00:04+00:00

[ Upstream commit 0cc114dc358cf8da2ca23a366e761e89a46ca277 ] When a module registers a struct_ops, the struct_ops type and its corresponding map_value type ("bpf_struct_ops_") may reside in different btf objects, here are four possible case: +--------+---------------+-------------+---------------------------------+ | |bpf_struct_ops_| xxx_ops | | +--------+---------------+-------------+---------------------------------+ | case 0 | btf_vmlinux | btf_vmlinux | be used and reg only in vmlinux | +--------+---------------+-------------+---------------------------------+ | case 1 | btf_vmlinux | mod_btf | INVALID | +--------+---------------+-------------+---------------------------------+ | case 2 | mod_btf | btf_vmlinux | reg in mod but be used both in | | | | | vmlinux and mod. | +--------+---------------+-------------+---------------------------------+ | case 3 | mod_btf | mod_btf | be used and reg only in mod | +--------+---------------+-------------+---------------------------------+ Currently we figure out the mod_btf by searching with the struct_ops type, which makes it impossible to figure out the mod_btf when the struct_ops type is in btf_vmlinux while it's corresponding map_value type is in mod_btf (case 2). The fix is to use the corresponding map_value type ("bpf_struct_ops_") as the lookup anchor instead of the struct_ops type to figure out the `btf` and `mod_btf` via find_ksym_btf_id(), and then we can locate the kern_type_id via btf__find_by_name_kind() with the `btf` we just obtained from find_ksym_btf_id(). With this change the lookup obtains the correct btf and mod_btf for case 2, preserves correct behavior for other valid cases, and still fails as expected for the invalid scenario (case 1). Fixes: 590a00888250 ("bpf: libbpf: Add STRUCT_OPS support") Signed-off-by: D. Wythe Signed-off-by: Andrii Nakryiko Acked-by: Andrii Nakryiko Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20250926071751.108293-1-alibuda@linux.alibaba.com Signed-off-by: Sasha Levin

tools/nolibc: make time_t robust if __kernel_old_time_t is missing in host headers

2025-10-15T10:00:02+00:00

[ Upstream commit 0ff52df6b32a6b04a7c9dfe3d7a387aff215b482 ] Commit d5094bcb5bfd ("tools/nolibc: define time_t in terms of __kernel_old_time_t") made nolibc use the kernel's time type so that `time_t` matches `timespec::tv_sec` on all ABIs (notably x32). But since __kernel_old_time_t is fairly new, notably from 2020 in commit 94c467ddb273 ("y2038: add __kernel_old_timespec and __kernel_old_time_t"), nolibc builds that rely on host headers may fail. Switch to __kernel_time_t, which is the same as __kernel_old_time_t and has existed for longer. Tested in PPC VM of Open Source Lab of Oregon State University (./tools/testing/selftests/rcutorture/bin/mkinitrd.sh) Fixes: d5094bcb5bfd ("tools/nolibc: define time_t in terms of __kernel_old_time_t") Signed-off-by: Zhouyi Zhou [Thomas: Reformat commit and its message a bit] Signed-off-by: Thomas Weißschuh Signed-off-by: Sasha Levin

selftests: watchdog: skip ping loop if WDIOF_KEEPALIVEPING not supported

2025-10-15T10:00:02+00:00

[ Upstream commit e8cfc524eaf3c0ed88106177edb6961e202e6716 ] Check if watchdog device supports WDIOF_KEEPALIVEPING option before entering keep_alive() ping test loop. Fix watchdog-test silently looping if ioctl based ping is not supported by the device. Exit from test in such case instead of getting stuck in loop executing failing keep_alive() watchdog_info: identity: m41t93 rtc Watchdog firmware_version: 0 Support/Status: Set timeout (in seconds) Support/Status: Watchdog triggers a management or other external alarm not a reboot Watchdog card disabled. Watchdog timeout set to 5 seconds. Watchdog ping rate set to 2 seconds. Watchdog card enabled. WDIOC_KEEPALIVE not supported by this device without this change Watchdog card disabled. Watchdog timeout set to 5 seconds. Watchdog ping rate set to 2 seconds. Watchdog card enabled. Watchdog Ticking Away! (Where test stuck here forver silently) Updated change log at commit time: Shuah Khan Link: https://lore.kernel.org/r/20250914152840.GA3047348@bhairav-test.ee.iitb.ac.in Fixes: d89d08ffd2c5 ("selftests: watchdog: Fix ioctl SET* error paths to take oneshot exit path") Signed-off-by: Akhilesh Patil Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin

selftests: vDSO: vdso_test_abi: Correctly skip whole test with missing vDSO

2025-10-15T09:59:59+00:00

[ Upstream commit 4b59a9f7628fd82b24f2148f62cf327a84d26555 ] If AT_SYSINFO_EHDR is missing the whole test needs to be skipped. Currently this results in the following output: TAP version 13 1..16 # AT_SYSINFO_EHDR is not present! This output is incorrect, as "1..16" still requires the subtest lines to be printed, which isn't done however. Switch to the correct skipping functions, so the output now correctly indicates that no subtests are being run: TAP version 13 1..0 # SKIP AT_SYSINFO_EHDR is not present! Fixes: 693f5ca08ca0 ("kselftest: Extend vDSO selftest") Signed-off-by: Thomas Weißschuh Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/all/20250812-vdso-tests-fixes-v2-2-90f499dd35f8@linutronix.de Signed-off-by: Sasha Levin

selftests: vDSO: Fix -Wunitialized in powerpc VDSO_CALL() wrapper

2025-10-15T09:59:59+00:00

[ Upstream commit 9f15e0f9ef514b8e1a80707931f6d07362e8ebc4 ] The _rval register variable is meant to be an output operand of the asm statement but is instead used as input operand. clang 20.1 notices this and triggers -Wuninitialized warnings: tools/testing/selftests/timers/auxclock.c:154:10: error: variable '_rval' is uninitialized when used here [-Werror,-Wuninitialized] 154 | return VDSO_CALL(self->vdso_clock_gettime64, 2, clockid, ts); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ tools/testing/selftests/timers/../vDSO/vdso_call.h:59:10: note: expanded from macro 'VDSO_CALL' 59 | : "r" (_rval) \ | ^~~~~ tools/testing/selftests/timers/auxclock.c:154:10: note: variable '_rval' is declared here tools/testing/selftests/timers/../vDSO/vdso_call.h:47:2: note: expanded from macro 'VDSO_CALL' 47 | register long _rval asm ("r3"); \ | ^ It seems the list of input and output operands have been switched around. However as the argument registers are not always initialized they can not be marked as pure inputs as that would trigger -Wuninitialized warnings. Adding _rval as another input and output operand does also not work as it would collide with the existing _r3 variable. Instead reuse _r3 for both the argument and the return value. Fixes: 6eda706a535c ("selftests: vDSO: fix the way vDSO functions are called for powerpc") Reported-by: kernel test robot Signed-off-by: Thomas Weißschuh Signed-off-by: Thomas Gleixner Reviewed-by: Christophe Leroy Link: https://lore.kernel.org/all/20250812-vdso-tests-fixes-v2-1-90f499dd35f8@linutronix.de Closes: https://lore.kernel.org/oe-kbuild-all/202506180223.BOOk5jDK-lkp@intel.com/ Signed-off-by: Sasha Levin

selftests/nolibc: fix EXPECT_NZ macro

2025-10-15T09:59:58+00:00

[ Upstream commit 6d33ce3634f99e0c6c9ce9fc111261f2c411cb48 ] The expect non-zero macro was incorrect and never used. Fix its definition. Fixes: 362aecb2d8cfa ("selftests/nolibc: add basic infrastructure to ease creation of nolibc tests") Signed-off-by: Benjamin Berg Link: https://lore.kernel.org/r/20250731201225.323254-2-benjamin@sipsolutions.net Signed-off-by: Thomas Weißschuh Signed-off-by: Sasha Levin

libbpf: Fix reuse of DEVMAP

2025-10-15T09:59:56+00:00

[ Upstream commit 6c6b4146deb12d20f42490d5013f2043df942161 ] Previously, re-using pinned DEVMAP maps would always fail, because get_map_info on a DEVMAP always returns flags with BPF_F_RDONLY_PROG set, but BPF_F_RDONLY_PROG being set on a map during creation is invalid. Thus, ignore the BPF_F_RDONLY_PROG flag in the flags returned from get_map_info when checking for compatibility with an existing DEVMAP. The same problem is handled in a third-party ebpf library: - https://github.com/cilium/ebpf/issues/925 - https://github.com/cilium/ebpf/pull/930 Fixes: 0cdbb4b09a06 ("devmap: Allow map lookups from eBPF") Signed-off-by: Yureka Lilian Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250814180113.1245565-3-yuka@yuka.dev Signed-off-by: Sasha Levin

bpf/selftests: Fix test_tcpnotify_user

2025-10-15T09:59:56+00:00

[ Upstream commit c80d79720647ed77ebc0198abd5a0807efdaff0b ] Based on a bisect, it appears that commit 7ee988770326 ("timers: Implement the hierarchical pull model") has somehow inadvertently broken BPF selftest test_tcpnotify_user. The error that is being generated by this test is as follows: FAILED: Wrong stats Expected 10 calls, got 8 It looks like the change allows timer functions to be run on CPUs different from the one they are armed on. The test had pinned itself to CPU 0, and in the past the retransmit attempts also occurred on CPU 0. The test had set the max_entries attribute for BPF_MAP_TYPE_PERF_EVENT_ARRAY to 2 and was calling bpf_perf_event_output() with BPF_F_CURRENT_CPU, so the entry was likely to be in range. With the change to allow timers to run on other CPUs, the current CPU tasked with performing the retransmit might be bumped and in turn fall out of range, as the event will be filtered out via __bpf_perf_event_output() using: if (unlikely(index >= array->map.max_entries)) return -E2BIG; A possible change would be to explicitly set the max_entries attribute for perf_event_map in test_tcpnotify_kern.c to a value that's at least as large as the number of CPUs. As it turns out however, if the field is left unset, then the libbpf will determine the number of CPUs available on the underlying system and update the max_entries attribute accordingly in map_set_def_max_entries(). A further problem with the test is that it has a thread that continues running up until the program exits. The main thread cleans up some LIBBPF data structures, while the other thread continues to use them, which inevitably will trigger a SIGSEGV. This can be dealt with by telling the thread to run for as long as necessary and doing a pthread_join on it before exiting the program. Finally, I don't think binding the process to CPU 0 is meaningful for this test any more, so get rid of that. Fixes: 435f90a338ae ("selftests/bpf: add a test case for sock_ops perf-event notification") Signed-off-by: Matt Bobrowski Signed-off-by: Martin KaFai Lau Acked-by: Stanislav Fomichev Link: https://patch.msgid.link/aJ8kHhwgATmA3rLf@google.com Signed-off-by: Sasha Levin

selftests: arm64: Check fread return value in exec_target

2025-10-15T09:59:54+00:00

[ Upstream commit a679e5683d3eef22ca12514ff8784b2b914ebedc ] Fix -Wunused-result warning generated when compiled with gcc 13.3.0, by checking fread's return value and handling errors, preventing potential failures when reading from stdin. Fixes compiler warning: warning: ignoring return value of 'fread' declared with attribute 'warn_unused_result' [-Wunused-result] Fixes: 806a15b2545e ("kselftests/arm64: add PAuth test for whether exec() changes keys") Signed-off-by: Bala-Vignesh-Reddy Reviewed-by: Mark Brown Signed-off-by: Will Deacon Signed-off-by: Sasha Levin