kernel/git/stable/linux-stable.git/tools, branch linux-rolling-lts

sched_ext: Fix inverted ops.core_sched_before() invocation

2026-09-11T09:49:40+00:00

[ Upstream commit f7b6d128dd49a6eec09066ecfd29095f12588786 ] scx_prio_less() implements prio_less() semantics - %true means that @a is the lower priority and should run after @b. ops.core_sched_before() is documented to return %true when @a should run before @b. scx_prio_less() returns the op's value as-is, inverting the documented semantics at runtime. Call the op with the arguments swapped. scx_qmap followed the wiring instead of the documentation and returned %true for the younger task, so the two inversions canceled out and it behaved as intended. Flip its comparison to match. scx_qmap is likely the only current user in or out of the kernel tree. Any scheduler written the same way needs the same flip, while schedulers following the documentation are fixed by this change. Fixes: 7b0888b7cc19 ("sched_ext: Implement core-sched support") Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: Tejun Heo [ adapted kernel/sched/ext/ext.c changes to the older kernel/sched/ext.c layout ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

cxl/pci: Move CXL driver's RCH error handling into core/ras_rch.c

2026-09-11T09:49:37+00:00

[ Upstream commit 0ff60f2ec3e4043a442e805f80f8a2445113ec8f ] Restricted CXL Host (RCH) protocol error handling uses a procedure distinct from the CXL Virtual Hierarchy (VH) handling. This is because of the differences in the RCH and VH topologies. Improve the maintainability and add ability to enable/disable RCH handling. Move and combine the RCH handling code into a single block conditionally compiled with the CONFIG_CXL_RCH_RAS kernel config. Signed-off-by: Terry Bowman Reviewed-by: Jonathan Cameron Reviewed-by: Dave Jiang Link: https://patch.msgid.link/20260114182055.46029-9-terry.bowman@amd.com Signed-off-by: Dan Williams Signed-off-by: Dave Jiang Stable-dep-of: 29458e62d082 ("cxl/ras: Fix cxl_rch_get_aer_info() out-of-bounds AER register read") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

perf hisi-ptt: Fix PTT trace TLP header parsing

2026-09-11T09:49:14+00:00

commit 2b8a2e5d424f0b3369054305d0bf6a5b9faee6c1 upstream. TLP Headers traced by HiSilicon PCIe tune and trace device (PTT) in 4DW format are shown in the document as below: bits [31:30] [ 29:25 ][24][23][22][21][ 20:11 ][ 10:0 ] |-----|---------|---|---|---|---|-------------|-------------| DW0 [ Fmt ][ Type ][T9][T8][TH][SO][ Length ][ Time ] DW1 [ Header DW1 ] DW2 [ Header DW2 ] DW3 [ Header DW3 ] Problem: The DW0 bit field layout of the hisi_ptt_4dw union does not match the actual bit ordering in little-endian memory, causing incorrect field decoding. Test on Kunpeng 930 SOC, generating data flow with `iperf` commands: - server side: iperf -s - client side: iperf -c $ip_addr -t 30 Trace the TLP headers with hisi_ptt on server side at the same time: perf record -e hisi_ptt12_0/type=4,filter=0x05101,direction=2,format=0/ \ --max-size 50M -o perf.data & The trace aims to capture completion TLPs, learn more in the document: https://docs.kernel.org/trace/hisi-ptt.html Decode perf.data with hisi_ptt decoder: perf report -D The hisi_ptt decoder produces the following result: [...perf headers and other information] . ... HISI PTT data: size 8388608 bytes . 00000000: 68 87 20 94 Format 3 Type 1a T9 0 T8 1 TH 1 SO 1 Length 10 Time 4a1 . 00000004: 40 00 00 00 Header DW1 . 00000008: 40 00 01 51 Header DW2 . 0000000c: 00 00 00 00 Header DW3 [...other hisi_ptt TLP headers] According to PCIe r5.0 sec 2.2.1, the Fmt & Type of Cpl/CplD is supposed to be 8b'00001010' / 8b'01001010' However, the Format & Type decoder analyzing result is 8b'01111010'. It does not match field encodings of any TLP. Correct decoder result should be: [...perf headers and other information] . ... HISI PTT data: size 8388608 bytes . 00000000: 94 20 87 68 Format 2 Type a T9 0 T8 0 TH 0 SO 1 Length 10 Time 768 . 00000004: 00 00 00 40 Header DW1 . 00000008: 51 01 00 40 Header DW2 . 0000000c: 00 00 00 00 Header DW3 [...other hisi_ptt TLP headers] To solve the problem: 1. Drop the union and C bitfield struct, store the raw DW value in a plain uint32_t, and extract the fields with FIELD_GET() against GENMASK/BIT masks declared in the header so they can be reused by other translation units. The masks are portable across endianness and compilers. 2. Print all DW hex values in big-endian byte order for readability, matching the bit field layout shown in the 4DW format diagram. 3. Read the DW value with get_unaligned_le32() instead of an unaligned pointer cast, avoiding both strict-aliasing violations and alignment hazards on hosts that do not support unaligned access. Cc: stable@vger.kernel.org Fixes: 5e91e57e6809 ("perf auxtrace arm64: Add support for parsing HiSilicon PCIe Trace packet") Reviewed-by: James Clark Signed-off-by: Sizhe Liu Signed-off-by: Namhyung Kim Signed-off-by: Greg Kroah-Hartman

perf trace: Refactor augmented_raw_syscalls using bpf_for

2026-09-11T09:49:13+00:00

commit ea6992784d65ef2c01f3525217dbf3a44afa9917 upstream. The loop for processing syscall args in augment_raw_syscalls has a history of breaking with Clang updates, see e.g. commit 013eb043f37b ("perf trace: Fix BPF loading failure (-E2BIG)") from Clang 15 to 16. Now, a similar thing happened between Clang 21 and 22. While the issue is mitigated on the main line by a recent verifier update, it remains broken on the 6.12 and 6.18 stable branches: [linux-6.18.y]# sudo perf trace true libbpf: prog 'sys_enter': BPF program load failed: -E2BIG libbpf: prog 'sys_enter': -- BEGIN PROG LOAD LOG -- [...] BPF program is too large. Processed 1000001 insn processed 1000001 insns (limit 1000000) max_states_per_insn 40 total_states 37941 peak_states 232 mark_read 0 -- END PROG LOAD LOG -- libbpf: prog 'sys_enter': failed to load: -E2BIG libbpf: failed to load object 'augmented_raw_syscalls_bpf' libbpf: failed to load BPF skeleton 'augmented_raw_syscalls_bpf': -E2BIG Error: failed to get syscall or beauty map fd [...] The reason is that the loop is quite complex and the BPF verifier often struggles to prove that it terminates. Fix the issue by replacing the standard for loop with the bpf_for macro, which uses a numeric BPF iterator. This should prevent future breakages of this kind since the verifier has a much easier job proving that the loop terminates. Small adjustments were necessary for the loop to make it work. The main problem is that the verifier sometimes has problems with bpf_for loops that use a carry-over state, such as the `payload_offset` and `output` vars here, since the verifier tries to track their values too precisely and cannot prove loop convergence. To resolve the issue, we (1) explicitly recompute `payload_offset` in every iteration and (2) use a trick with adding a global zero to `output` to help the verifier forget its precise state and use a range instead. Finally, to keep backwards compatibility with older kernel versions that don't have bpf_for (i.e. numeric iterators), fall back to standard loop. Signed-off-by: Viktor Malik Cc: stable@vger.kernel.org Suggested-by: Andrii Nakryiko Fixes: a68fd6a6cdd3 ("perf trace: Collect augmented data using BPF") Signed-off-by: Namhyung Kim Signed-off-by: Greg Kroah-Hartman

perf trace: Factor out BPF loop body

2026-09-11T09:49:13+00:00

commit acff3e1a9cc29a6a039b76b81a438c56016bc0e3 upstream. The BPF program in augmented_raw_syscalls uses a for loop to iterate all syscall arguments. The loop body is quite complex and often poses problems for the BPF verifier. As a preparation step for addressing this issue, factor out the loop body into a separate function. Signed-off-by: Viktor Malik Cc: stable@vger.kernel.org Signed-off-by: Namhyung Kim Signed-off-by: Greg Kroah-Hartman

objtool/rust: add one more `noreturn` Rust function

2026-09-11T09:49:07+00:00

[ Upstream commit c18f35e4904920db4c51620ba634e4d175b24741 ] Fix the following warning: rust/kernel.o: warning: objtool: _RNvXNtNtCs1ewLyjEZ7Le_6kernel3str9parse_intaNtNtB2_7private12FromStrRadix14from_str_radix() falls through to next function _RNvXNtNtCs1ewLyjEZ7Le_6kernel3str9parse_intaNtNtB2_7private12FromStrRadix16from_u64_negated() The commit 51d9ee90ea90 ("rust: str: add radix prefixed integer parsing functions") introduces u64::from_str_radix(), whose implementation contains a panic path for out-of-range radix values. The panic helper is core::num::from_ascii_radix_panic(). Note that radix is derived from strip_radix() here and is always within the valid range, so kernel never panics. Fixes: 51d9ee90ea90 ("rust: str: add radix prefixed integer parsing functions") Signed-off-by: FUJITA Tomonori Reviewed-by: Alice Ryhl Tested-by: Alice Ryhl Link: https://patch.msgid.link/20251223113538.1016078-1-fujita.tomonori@gmail.com [ Reworded typo. - Miguel ] Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin

selftests/mm: fix on-fault-limit false failure under sudo-rs

2026-09-07T15:23:00+00:00

commit 98df164036bed307a16e7c124ad023c2c13c4b76 upstream. run_vmtests.sh runs on-fault-limit as the nobody user via "sudo -u nobody ./on-fault-limit", guarded by a check that nobody can access the binary ("sudo -u nobody ls ./on-fault-limit"). The guard resolves the relative path from the inherited working directory, which only requires search permission on the test directory itself. Classic sudo passes the relative path through to execve() the same way, so the two agree. However, sudo-rs (the default sudo implementation since Ubuntu 25.10) canonicalizes the command to an absolute path before executing it, which requires search permission on every ancestor directory. When the kernel tree lives under a private home directory (mode 0750, the Ubuntu default for new users since 21.04), the guard passes but the execution fails with "command not found", and the test is reported as a false FAIL: # running sudo -u nobody ./on-fault-limit sudo: './on-fault-limit': command not found # [FAIL] Wrap the command in "sh -c" so that sudo only resolves the shell binary, and the relative path is resolved by nobody's shell from the inherited working directory, matching what the guard checks. This is the only "sudo -u nobody" invocation in the script; uid, cwd, rlimits (including RLIMIT_MEMLOCK, which this test exercises) and the exit status are unchanged through sh. Verified on Ubuntu 26.04 (sudo-rs 0.2.13): the test now runs and passes instead of failing. Verified on Ubuntu 24.04 (sudo 1.9.15p5): behavior is unchanged. Link: https://lore.kernel.org/20260713092700.464376-1-injaeryou@gmail.com Fixes: 5d2146a3354f ("selftests/mm: skip mlock tests if nobody user can't read it") Signed-off-by: Injae Ryou Cc: Brendan Jackman Cc: Brendan Jackman Cc: David Hildenbrand Cc: Lorenzo Stoakes Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman

tools/compiler: match glibc 2.42 definition of __attribute_const__

2026-09-07T15:22:23+00:00

commit 8700a4761beb219873956666cf91776a2c61e698 upstream. glibc 2.42 added __attribute_const__ to sys/cdefs.h: # define __attribute_const__ __attribute__ ((__const__)) GCC 15 warns when a macro is redefined to a different replacement list (-Wbuiltin-macro-redefined). Since host tool Makefiles (resolve_btfids, objtool) pass -Werror, this conflict becomes fatal. The warning is suppressed on standard native builds because GCC treats /usr/include as a system header path (-isystem), and macro-redefinition warnings from system headers are silently suppressed by GCC. It fires when glibc headers are on a regular include path (-I) instead, which is the case in cross-compilation setups such as NixOS, where the sysroot's glibc is passed explicitly via -I rather than -isystem. Per (C11 6.10.3), identical replacement lists are accepted silently. Match the glibc definition exactly, including the space before "((", so the redefinition is accepted without warning regardless of whether glibc headers are treated as system or non-system includes. Link: https://lore.kernel.org/20260701200635.3992767-1-rkr0k0r@gmail.com Signed-off-by: Joy H.J. Lee Cc: Nathan Chancellor Cc: David Laight Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman

selftests/ftrace: Convert ELF entry point to file offset in uprobe test

2026-08-23T12:26:57+00:00

commit 24aa630f6259e6a2107936c06fed72063f712b64 upstream. The add_remove_uprobe test uses readelf -h to obtain the ELF entry point (e_entry) and passes it directly as the offset to uprobe_events. However, uprobe_events expects a file offset, not a virtual address. For PIE binaries, the virtual address happens to equal the file offset because the first LOAD segment has p_vaddr == p_offset, so the test works by coincidence. But for non-PIE executables, e_entry is an absolute virtual address that can far exceed the file size. When the probe is enabled, uprobe_register() checks offset > i_size_read(inode) and rejects it with -EINVAL. Fix this by converting the virtual address to a file offset using the ELF program headers: scan readelf -lW output for the LOAD segment containing the entry point, then compute file_offset = e_entry - p_vaddr + p_offset. For PIE binaries the result is unchanged; for non-PIE binaries the offset is correctly translated. The conversion uses only POSIX shell primitives, with no dependency on gawk or perl. Link: https://lore.kernel.org/all/20260807081512.2974757-3-qirui.001@bytedance.com/ Fixes: dc4b165855f2 ("selftests/ftrace: Use readelf to find entry point in uprobe test") Cc: stable@vger.kernel.org Signed-off-by: Rui Qi Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Greg Kroah-Hartman

selftests: mptcp: join: mark tests with data corruption as failed

2026-08-23T12:26:54+00:00

commit ca318e7bbb7723f57bcd9e69a2873b5884435552 upstream. check_transfer() compares the input and output files byte-by-byte using `cmp -l "$in" "$out" | while read ...`. Because the while-loop body runs in a subshell (the script sets neither lastpipe nor pipefail), the fail_test call inside it -- which sets the global ret/last_test_failed -- and the `return 1` both act on the subshell, not on check_transfer(). check_transfer() thus always falls through to `return 0`, and any data corruption affecting only the payload (leaving the subflow/PM counters untouched) is silently reported as PASS. Fixes: 8117dac3e7c3 ("selftests: mptcp: add invert check in check_transfer") Cc: stable@vger.kernel.org Signed-off-by: Gang Yan Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-5-b8f496d71664@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman