summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-08-07riscv: kprobes: Prevent probes in breakpoint handlersRui Qi
The ftrace selftest multiple_kprobes.tc registers kprobe events on the first 256 text symbols from /proc/kallsyms. If handle_break() is selected as a probe target on RISC-V, the breakpoint exception path can trap again before it reaches the kprobe breakpoint handler. That recursively enters do_trap_break() and can make the system unresponsive. Mark handle_break() and its local probe dispatch helpers as nokprobe symbols so they are added to the kprobe blacklist, matching other low-level breakpoint exception paths. Signed-off-by: Rui Qi <qirui.001@bytedance.com> Reviewed-by: Nam Cao <namcao@linutronix.de> Link: https://patch.msgid.link/20260806043807.2583001-1-qirui.001@bytedance.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: cmpxchg: Use .option arch for Zacas and ZabhaVivian Wang
Instead of adding these to -march globally, use .option arch to use instructions from these extensions only in code paths where we know they are available, like how it is done for most other extensions. TOOLCHAIN_HAS_{ZACAS,ZABHA} already depend on AS_HAS_OPTION_ARCH, so this is not a functionality regression even on older assemblers. Although the compiler is unlikely to generate atomics on its own accord, this aligns handling of Zacas and Zabha with most other extensions and improves consistency on how assembly code requiring extra extensions is written in kernel code. This is analogous to the use of __LSE_PREAMBLE or .arch_extension lse in arm64 code. Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> Reviewed-by: Jesse Taube <jtaubepe@redhat.com> Link: https://patch.msgid.link/20260717-riscv-no-zacas-zabha-in-march-v1-1-82b5b0799fb6@iscas.ac.cn Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: acpi: Handle LPI architectural context loss flagsPeixin Xie
Commit 4785aa802853 ("cpuidle, ACPI: Evaluate LPI arch_flags for broadcast timer") replaced the generic nonzero check for LPI architectural context loss flags with arch_get_idle_state_flags(). RISC-V does not implement the helper, so it falls back to the stub that returns 0. Consequently, CPUIDLE_FLAG_TIMER_STOP is not set when an LPI state loses the hart timer context, preventing cpuidle from using a broadcast timer for that state. Implement the RISC-V helper and map the hart timer context loss flag to CPUIDLE_FLAG_TIMER_STOP. Fixes: 4785aa802853 ("cpuidle, ACPI: Evaluate LPI arch_flags for broadcast timer") Cc: stable@vger.kernel.org Acked-by: Sudeep Holla <sudeep.holla@kernel.org> Reviewed-by: Yixun Lan <dlan@kernel.org> Reviewed-by: Sunil V L <sunilvl@oss.qualcomm.com> Reviewed-by: Huisong Li <lihuisong@huawei.com> Signed-off-by: Peixin Xie <peixin.xie@linux.spacemit.com> Link: https://patch.msgid.link/20260803-riscv-acpi-lpi-timer-v3-1-520fa13732f5@linux.spacemit.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: further remove XIPJisheng Zhang
After commit 9b3a2be84803 ("riscv: Remove support for XIP kernel"), something relatd with XIP are still there. Remove them to clean up the code. Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Reviewed-by: Nam Cao <namcao@linutronix.de> Link: https://patch.msgid.link/20260805010049.13918-1-jszhang@kernel.org Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: Add support for srmcfg CSR from Ssqosid extensionDrew Fustini
Add support for the srmcfg CSR defined in the Ssqosid ISA extension. The CSR contains two fields: - Resource Control ID (RCID) for resource allocation - Monitoring Counter ID (MCID) for tracking resource usage Requests from a hart to shared resources are tagged with these IDs, allowing resource usage to be associated with the running task. Add a srmcfg field to thread_struct with the same format as the CSR. The context-switch path writes the field to the CSR, and resctrl_arch_set_closid_rmid() updates it when a task is assigned to a resctrl control or monitoring group. A per-cpu cpu_srmcfg_default holds the default srmcfg for each CPU, set by resctrl_arch_set_cpu_default_closid_rmid() on CPU group assignment. On context switch, RCID and MCID inherit from the CPU default independently: a task whose thread RCID field is zero takes the CPU default's RCID, and likewise for MCID. A per-cpu cpu_srmcfg variable mirrors the CSR state to avoid redundant writes. L1D-hot memory access is faster than a CSR read and avoids traps under virtualization. Link: https://github.com/riscv/riscv-ssqosid/releases/tag/v1.0 Assisted-by: Claude:claude-opus-4-7 Co-developed-by: Kornel Dulęba <mindal@semihalf.com> Signed-off-by: Kornel Dulęba <mindal@semihalf.com> Signed-off-by: Drew Fustini <fustini@kernel.org> Link: https://patch.msgid.link/20260729-dfustini-atl-sc-cbqri-dt-v6-3-7c22b05d461b@kernel.org Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: Detect the Ssqosid extensionDrew Fustini
Ssqosid is the RISC-V Quality-of-Service (QoS) Identifiers specification which defines the Supervisor Resource Management Configuration (srmcfg) register. Link: https://github.com/riscv/riscv-ssqosid/releases/tag/v1.0 Co-developed-by: Kornel Dulęba <mindal@semihalf.com> Signed-off-by: Kornel Dulęba <mindal@semihalf.com> Signed-off-by: Drew Fustini <fustini@kernel.org> Link: https://patch.msgid.link/20260729-dfustini-atl-sc-cbqri-dt-v6-2-7c22b05d461b@kernel.org [pjw@kernel.org: updated to apply] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07dt-bindings: riscv: Add Ssqosid extension descriptionDrew Fustini
Document the ratified Supervisor-mode Quality of Service ID (Ssqosid) extension v1.0. Link: https://github.com/riscv/riscv-ssqosid/releases/tag/v1.0 Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Drew Fustini <fustini@kernel.org> Link: https://patch.msgid.link/20260729-dfustini-atl-sc-cbqri-dt-v6-1-7c22b05d461b@kernel.org Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07dt-bindings: riscv: add Counter delegation ISA extensions descriptionAtish Patra
Add description for the Smcdeleg/Ssccfg extension. Signed-off-by: Atish Patra <atishp@rivosinc.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/20260807-counter_delegation-v9-10-58658104e487@meta.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07RISC-V: Add Ssccfg/Smcdeleg ISA extension definition and parsingAtish Patra
Smcdeleg extension allows the M-mode to delegate selected counters to S-mode so that it can access those counters and correpsonding hpmevent CSRs without M-mode. Ssccfg (‘Ss’ for Privileged architecture and Supervisor-level extension, ‘ccfg’ for Counter Configuration) provides access to delegated counters and new supervisor-level state. This patch just enables these definitions and enable parsing. Signed-off-by: Atish Patra <atishp@rivosinc.com> Reviewed-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Link: https://patch.msgid.link/20260807-counter_delegation-v9-9-58658104e487@meta.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07RISC-V: Add Ssccfg extension CSR definitionKaiwen Xue
This adds the scountinhibit CSR definition and S-mode accessible hpmevent bits defined by smcdeleg/ssccfg. scountinhibit allows S-mode to start/stop counters directly from S-mode without invoking SBI calls to M-mode. It is also used to figure out the counters delegated to S-mode by the M-mode as well. Signed-off-by: Kaiwen Xue <kaiwenx@rivosinc.com> Reviewed-by: Clément Léger <cleger@rivosinc.com> Reviewed-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Tested-by: Charlie Jenkins <thecharlesjenkins@gmail.com> [pjw@kernel.org: fixed subject typo] Link: https://patch.msgid.link/20260807-counter_delegation-v9-8-58658104e487@meta.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07dt-bindings: riscv: add Smcntrpmf ISA extension descriptionAtish Patra
Add the description for Smcntrpmf ISA extension Acked-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Atish Patra <atishp@rivosinc.com> Link: https://patch.msgid.link/20260807-counter_delegation-v9-7-58658104e487@meta.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07RISC-V: Add Smcntrpmf extension parsingAtish Patra
Smcntrpmf extension allows M-mode to enable privilege mode filtering for cycle/instret counters. However, the cyclecfg/instretcfg CSRs are available in Ssccfg only if Smcntrpmf is present. That's why, kernel needs to detect presence of Smcntrpmf extension and enable privilege mode filtering for cycle/instret counters. Reviewed-by: Clément Léger <cleger@rivosinc.com> Signed-off-by: Atish Patra <atishp@rivosinc.com> Reviewed-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Tested-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Link: https://patch.msgid.link/20260807-counter_delegation-v9-6-58658104e487@meta.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07RISC-V: Define indirect CSR access helpersAtish Patra
The indirect CSR requires multiple instructions to read/write CSR. Add a few helper macros for ease of usage. These have to be macros rather than functions. csr_read()/csr_write() stringify their CSR argument into the inline asm template via __ASM_STR(), so the CSR number must be a literal token; passing it as a function parameter emits "csrr %0, iregcsr", which the assembler rejects with "unknown CSR `iregcsr'". The stringification happens in the preprocessor, before inlining or constant propagation, so it cannot be worked around by forcing inlining or by only ever passing constants - gcc 12, gcc 16 and clang 22 all reject it alike. Underneath, csrr/csrw encode the CSR as a 12-bit immediate and RISC-V has no register-indirect form, which is also why asm/csr.h keeps every one of its accessors as a macro. Signed-off-by: Atish Patra <atishp@rivosinc.com> Reviewed-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Tested-by: Charlie Jenkins <thecharlesjenkins@gmail.com> [pjw@kernel.org: expand "ind" abbreviation] Link: https://patch.msgid.link/20260807-counter_delegation-v9-5-58658104e487@meta.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07dt-bindings: riscv: add Smcsrind and Sscsrind ISA extension descriptionsAtish Patra
Add the S[m|s]csrind ISA extension description. Acked-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Atish Patra <atishp@rivosinc.com> [pjw@kernel.org: use official extension names in the patch description] Link: https://patch.msgid.link/20260807-counter_delegation-v9-4-58658104e487@meta.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07RISC-V: Add Smcsrind and Sscsrind ISA extension definition and parsingAtish Patra
The S[m|s]csrind extensions extend the indirect CSR access mechanism defined in Smaia/Ssaia extensions. This patch just enables the definition and parsing. Signed-off-by: Atish Patra <atishp@rivosinc.com> Reviewed-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Tested-by: Charlie Jenkins <thecharlesjenkins@gmail.com> [pjw@kernel.org: use official RISC-V extension names in the patch description] Link: https://patch.msgid.link/20260807-counter_delegation-v9-3-58658104e487@meta.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07RISC-V: Add Smcsrind and Sscsrind ISA extension CSR definitionsKaiwen Xue
This adds definitions of new CSRs and bits defined in the Smcsrind and Sscsrind ISA extensions. These CSRs enable the indirect CSR accesses mechanism to access any indirect CSRs in M-, S-, and VS-mode. The range of the select values and ireg will be defined by the ISA extension that are based on the Smcsrind and Sscsrind extensions. Signed-off-by: Kaiwen Xue <kaiwenx@rivosinc.com> Reviewed-by: Clément Léger <cleger@rivosinc.com> Signed-off-by: Atish Patra <atishp@rivosinc.com> Reviewed-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Tested-by: Charlie Jenkins <thecharlesjenkins@gmail.com> [pjw@kernel.org: clean up the patch description; use official RISC-V extension names] Link: https://patch.msgid.link/20260807-counter_delegation-v9-2-58658104e487@meta.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07RISC-V: perf: fix resource cleanup on driver probe failureAtish Patra
Sashiko pointed out various UAF and memory leak issues around pmu_sbi_device_probe() error paths. If the probe fails, here are list of cleanups needed. a. Already registered pmu must be freed b. per cpu IRQ must be released c. pmu_ctr_list data structure must be freed d. cpu hotplug state must be cleaned up only if added. Fix the resource cleanup by reorganizing the code around probe failure. Reported-by: Sashiko AI <sashiko-bot@kernel.org> Reviewed-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Signed-off-by: Atish Patra <atishp@meta.com> Link: https://patch.msgid.link/20260807-counter_delegation-v9-1-58658104e487@meta.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07Revert "riscv: hwprobe: Fix stale vDSO data for late-initialized keys at boot"Nam Cao
This reverts commit 5d15d2ad36b0 ("riscv: hwprobe: Fix stale vDSO data for late-initialized keys at boot"). The commit ensures synchronization between the unaligned vector access speed probe kthread and vDSO data read. But now that the kthread has been removed, this commit can be reverted. Signed-off-by: Nam Cao <namcao@linutronix.de> Tested-by: Anirudh Srinivasan <asrinivasan@oss.tenstorrent.com> Link: https://patch.msgid.link/50ca78a649faf53f8941bc94c9cf8268b3644d38.1781666867.git.namcao@linutronix.de Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: unaligned: stop using kthread for check_vector_unaligned_access()Nam Cao
A kthread is used to run check_vector_unaligned_access() to optimize boot time, allowing the kernel to continue booting without waiting for the unaligned vector speed probe to finish. However, this asynchronous approach introduces several complications. First, the kthread may not complete before a user reads vDSO data, resulting in incorrect values. This was previously addressed by commit 5d15d2ad36b0 ("riscv: hwprobe: Fix stale vDSO data for late-initialized keys at boot"), which added complex synchronization between the kthread and vDSO reads. Second, it was discovered that the kthread may not finish before vec_check_unaligned_access_speed_all_cpus() (marked with __init) is freed, triggering a page fault. These issues raise the question of whether the kthread is worth the added complexity. A past boot time regression report was actually unrelated to synchronous probing; it was caused by the probe running serially. Since switching to a parallel probe, no further complaints have been made. Furthermore, the unaligned scalar access speed probe takes the same amount of time, runs synchronously, and has caused no issues. Testing shows no noticeable boot time slowdown when running the vector probe synchronously (0.464474s with kthread vs. 0.457991s without). Remove the kthread usage and run the probe synchronously. This simplifies the boot flow and allows for the revert of commit 5d15d2ad36b0 ("riscv: hwprobe: Fix stale vDSO data for late-initialized keys at boot") Reported-by: Anirudh Srinivasan <asrinivasan@oss.tenstorrent.com> Closes: https://lore.kernel.org/linux-riscv/20260612-vec_unaligned_drop_init-v1-1-df969210ae34@oss.tenstorrent.com/ Fixes: e7c9d66e313b ("RISC-V: Report vector unaligned access speed hwprobe") Cc: stable@vger.kernel.org Signed-off-by: Nam Cao <namcao@linutronix.de> Acked-by: Jesse Taube <jtaubepe@redhat.com> Tested-by: Anirudh Srinivasan <asrinivasan@oss.tenstorrent.com> Link: https://patch.msgid.link/1c378963f27c5960e8a57c50b8b444d30954cb54.1781666867.git.namcao@linutronix.de [pjw@kernel.org: updated to apply; adjusted Fixes: tag; fixed my own manual patch application error] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: Mark default_power_off() as __noreturnThorsten Blum
Since default_power_off() never returns, annotate it with the __noreturn attribute to improve compiler optimizations. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Link: https://patch.msgid.link/20260727100339.410466-2-thorsten.blum@linux.dev Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: mm: Move dma_contiguous_reserve() after NUMA initializationEder Zulian
Move the dma_contiguous_reserve() call from setup_bootmem() to misc_mem_init(), placing it after arch_numa_init(). This ensures that NUMA topology is initialized when reserving contiguous memory for DMA. Tested with CMA_SIZE_PERNUMA enabled and two NUMA nodes on QEMU: qemu-system-riscv64 \ -machine virt \ -nographic \ -smp 2 -m 512M \ -numa node,nodeid=0,cpus=0,memdev=m0 \ -numa node,nodeid=1,cpus=1,memdev=m1 \ -object memory-backend-ram,id=m0,size=256M \ -object memory-backend-ram,id=m1,size=256M \ -kernel arch/riscv/boot/Image \ -append "console=ttyS0 earlycon loglevel=7 cma=16M" Unpatched kernel's log (one global CMA pool and no per-nodepools, 16 MiB cma-reserved): [ 0.000000] cma: Reserved 16 MiB at 0x000000009ee00000 ... [ 0.000000] Initmem setup node 0 [mem 0x0000000080000000-0x000000008fffffff] [ 0.000000] Initmem setup node 1 [mem 0x0000000090000000-0x000000009fffffff] ... [ 0.056397] smp: Brought up 2 nodes, 2 CPUs [ 0.066135] Memory: 449288K/524288K available (12279K kernel code, 5980K rwdata, 6144K rodata, 2467K init, 482K bss, 54504K reserved, 16384K cma-reserved) Patched kernel's log (three CMA pools are created, 48 MiB total), [ 0.000000] cma: Reserved 16 MiB at 0x000000009ee00000 [ 0.000000] cma: Reserved 16 MiB at 0x000000008ee00000 [ 0.000000] cma: Reserved 16 MiB at 0x000000009de00000 ... [ 0.054251] smp: Brought up 2 nodes, 2 CPUs [ 0.064082] Memory: 416520K/524288K available (12279K kernel code, 5980K rwdata, 6144K rodata, 2467K init, 482K bss, 54504K reserved, 49152K cma-reserved) Signed-off-by: Eder Zulian <ezulian@redhat.com> Link: https://patch.msgid.link/20260714185648.1082483-1-ezulian@redhat.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: cfi: reduce shadow stack size limit from 2GB to 512MBZong Li
Change the shadow stack size calculation from RLIMIT_STACK/2 (capped at 2GB) to RLIMIT_STACK/8 (capped at 512MB), following David Laight's analysis and recommendation. Rationale: David Laight pointed out that the focus should be on the ratio between shadow stack size and the normal stack size, rather than just the absolute upper limit. His analysis showed that while there are many functions with small stack frames, the majority have stack deltas of over 64 bytes due to saved registers and local variables. Shadow stacks only store return addresses (8 bytes per entry on 64-bit systems), whereas normal stack frames typically consume 64+ bytes. This 8:64 byte ratio means that programs using a lot of stack space are dominated by large buffer allocations and local variables, not extreme recursion depths with minimal local data. For example, with the default RLIMIT_STACK of 8MB: - RLIMIT_STACK/2 gives a 4MB shadow stack supporting 512K nested calls - RLIMIT_STACK/8 gives a 1MB shadow stack supporting 128K nested calls Given typical stack frame sizes of 64+ bytes, RLIMIT_STACK/8 is still conservative and provides adequate depth for practical applications. David noted that this could even be safely halved again. This reduction also better accommodates memory-constrained platforms. On systems with limited physical memory, allocating large shadow stacks can cause virtual memory allocation failures when overcommit mode is set to OVERCOMMIT_GUESS or OVERCOMMIT_NEVER. Suggested-by: David Laight <david.laight.linux@gmail.com> Link: https://lore.kernel.org/all/20260518105725.7afe7a4c@pumpkin/ Signed-off-by: Zong Li <zong.li@sifive.com> Link: https://patch.msgid.link/20260522093634.3530233-1-zong.li@sifive.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: vdso: Simplify cflags remove logicThomas Weißschuh
Listing all flags for each object file is tedious and error-prone. Replace it with a simpler solution. Link: https://lore.kernel.org/all/20260630135316-f26f0e0f-c08c-4d4d-9963-10f9985a7689@linutronix.de/ Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Link: https://patch.msgid.link/20260701-riscv-vdso-lto-v1-2-89db0cd82077@linutronix.de Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: mm: Apply Svinval in update_mmu_cache()Xu Lu
Use Svinval in update_mmu_cache_range() when the extension is available. Signed-off-by: Xu Lu <luxu.kernel@bytedance.com> Link: https://patch.msgid.link/20260715132009.10634-3-luxu.kernel@bytedance.com Tested-by: Klara Modin <klarasmodin@gmail.com> Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: mm: Use ASID in update_mmu_cache()Xu Lu
Only flush TLB entries for the specified mm in update_mmu_cache_range(). Signed-off-by: Xu Lu <luxu.kernel@bytedance.com> Link: https://patch.msgid.link/20260715132009.10634-2-luxu.kernel@bytedance.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: kprobes: add test case for c.jal instruction simulationNam Cao
Add a test case validating that kprobes correctly simulates the c.jal instruction on RV32. The test uses two probe points: a forward c.jal and a backward c.jal, and verifies that the containing function returns the expected magic value KPROBE_TEST_MAGIC after kprobe interception. Co-developed-by: Xiaofeng Yuan <xiaofengmian@163.com> Signed-off-by: Nam Cao <namcao@linutronix.de> Signed-off-by: Xiaofeng Yuan <xiaofengmian@163.com> Reviewed-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Tested-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Link: https://patch.msgid.link/20260701081033.49871-3-xiaofengmian@163.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: probes: simulate c.jal instructionXiaofeng Yuan
The c.jal instruction is currently marked REJECTED in kprobes instruction decoding, but it should be SIMULATED like other compressed jump instructions. Add simulate_c_jal() which saves the return address to RA and sets the program counter to the target offset, reusing simulate_c_j for the common jump logic. Although c.jal is RV32-only, the function compiles unconditionally. On RV64, riscv_insn_is_c_jal() always returns 0, so the simulation code is never invoked and the small overhead in kernel size is acceptable. Signed-off-by: Xiaofeng Yuan <xiaofengmian@163.com> Reviewed-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Tested-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Reviewed-by: Nam Cao <namcao@linutronix.de> Tested-by: Nam Cao <namcao@linutronix.de> Link: https://patch.msgid.link/20260701081033.49871-2-xiaofengmian@163.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: acpi: Enable ARCH_HAS_ACPI_TABLE_UPGRADEVivian Wang
Implement the various required hooks and enable ARCH_HAS_ACPI_TABLE_UPGRADE to allow use for ACPI_TABLE_UPGRADE, which is useful for debugging ACPI table problems. The implementation is based on arm64's of the same feature due to the similarities of the requirements of the two platforms. Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> Link: https://patch.msgid.link/20260616-riscv-acpi-table-upgrade-v1-2-45902d2dedf9@iscas.ac.cn [pjw@kernel.org: updated to apply] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07ACPI: tables: Add missing #include <asm/fixmap.h>Vivian Wang
drivers/acpi/tables.c uses NR_FIX_BTMAPS without including <asm/fixmap.h>. This isn't a problem for existing archs, but would be when ARCH_HAS_ACPI_TABLE_UPGRADE is enabled for RISC-V. Add the missing include. Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> Link: https://patch.msgid.link/20260616-riscv-acpi-table-upgrade-v1-1-45902d2dedf9@iscas.ac.cn Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: Restart via EFI runtime services when availableAtish Patra
Firmware-preferred reset and EFI capsule update support requires reset via EFI runtime services rather than direction M-mode firmware invocation via SBI. Unlike poweroff, restart mechanism is directly controlled from machine_restart function though. Prefer the EFI runtime ResetSystem() service for restart when UEFI runtime services are available. Signed-off-by: Atish Patra <atishp@meta.com> Reviewed-by: Sunil V L <sunilvl@oss.qualcomm.com> Link: https://patch.msgid.link/20260615-efi_reset_shutdown-v1-2-9414edcbbab0@meta.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07riscv: efi: Power off via EFI runtime services when availableAtish Patra
When booted via UEFI with runtime services enabled, EFI Reset Shutdown is the firmware-preferred shutdown path: it lets firmware run its own shutdown hooks which may invoke SBI SRST extension internally. However, RISC-V always powers off via the SBI SRST extension today and EFI runtime path is never used even when firmware provides it. Enable the poweroff via EFI by overriding efi_poweroff_required() Signed-off-by: Atish Patra <atishp@meta.com> Reviewed-by: Sunil V L <sunilvl@oss.qualcomm.com> Link: https://patch.msgid.link/20260615-efi_reset_shutdown-v1-1-9414edcbbab0@meta.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-08-07MAINTAINERS: add Ivan Vecera as DPLL reviewerJiri Pirko
Ivan has been continuously active in DPLL development and discussion since April 2025. His contributions cover the DPLL core and API, netlink, bindings, ICE/SyncE integration, and the ZL3073x driver. He also regularly reviews and tests DPLL patches from other contributors and already maintains the Microchip ZL3073x driver. Add him as a reviewer to reflect his ongoing involvement across the subsystem. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Acked-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Acked-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Link: https://patch.msgid.link/20260806094432.163833-1-jiri@resnulli.us Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-07mailmap: add entries for Christoph PaaschChristoph Paasch
Map the email addresses used for previous kernel contributions to the current OpenAI address. This prevents get_maintainer.pl from listing historical addresses as patch recipients. Suggested-by: Matthieu Baerts <matttbe@kernel.org> Signed-off-by: Christoph Paasch <cpaasch@openai.com> Acked-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260806-b4-mailman-v1-1-b4d7bc0ffd1c@openai.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-07Merge branch 'net-wangxun-timeout-and-error'Jakub Kicinski
Jiawen Wu says: ==================== net: wangxun: timeout and error It is about adding the Tx timeout process and pci_error_handlers. When a PCIe error occurs, the txgbe device is able to recover on platform that support AER interrupt. And for Tx timeout, the txgbe driver can recover the device by reset process. For ngbe devices, due to the absence of the current function, it cannot br fully recovered once there is a PCIe error or Tx timeout. Its function will be completed in the future. ==================== Link: https://patch.msgid.link/20260803064334.21876-1-jiawenwu@trustnetic.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-07net: wangxun: add pcie error handlerJiawen Wu
Support AER driver to handle the PCIe errors. Sometimes netdev watchdog Tx timeout happens before the AER error report when a PCIe error occurs, CPU blocking would be caused by MMIO during the reset process. To prevent it, check PCIe error status in .ndo_tx_timeout. The current function of ngbe is not yet fully developed, it will be completed in the future. Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com> Link: https://patch.msgid.link/20260803064334.21876-6-jiawenwu@trustnetic.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-07net: wangxun: implement soft quiesce for PCIe error recoveryJiawen Wu
Function wx_soft_quiesce() provide a lightweight shutdown path during PCIe error recovery. It avoids MMIO-dependent operations in PCIe error status. Waiting for the service task to complete may unnecessarily delay PCIe error recovery, especially if the work item is already blocked by the hardware failure that triggered AER. So the service task is not explicitly cancelled in quiesce path. As a measure to block the service task, the checking of WX_STATE_DOWN and WX_STATE_RESETTING is added at the entry of relevant work item. Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Link: https://patch.msgid.link/20260803064334.21876-5-jiawenwu@trustnetic.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-07net: wangxun: add reinit parameter to wx->do_reset callbackJiawen Wu
To implement a simple hardware reset without tearing down the network interface state, introduce a boolean 'reinit' parameter to wx->do_reset callback. Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Link: https://patch.msgid.link/20260803064334.21876-4-jiawenwu@trustnetic.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-07net: wangxun: add Tx timeout processJiawen Wu
Implement .ndo_tx_timeout to handle Tx side timeout event. When a Tx timeout event occur, it will trigger driver into reset process. And allocate a separate work queue for reset process. The WX_HANG_CHECK_ARMED bit is set to indicate a potential hang. It will be cleared if a pause frame is received to avoid false hang detection caused by pause frames. Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com> Link: https://patch.msgid.link/20260803064334.21876-3-jiawenwu@trustnetic.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-07net: ngbe: implement libwx reset opsJiawen Wu
Implement wx->do_reset() for library module calling. Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com> Reviewed-by: Larysa Zaremba <larysa.zaremba@intel.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20260803064334.21876-2-jiawenwu@trustnetic.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-07tracing/mmiotrace: Use trace_assign_type() in mmio_print_mark()Masami Hiramatsu (Google)
In mmio_print_mark(), a raw C cast (struct print_entry *)entry is used to obtain the print_entry pointer. Use the standard trace_assign_type() macro instead, matching the usage in mmio_print_rw() and mmio_print_map(). Link: https://patch.msgid.link/178524301013.56416.9116249028160618790.stgit@devnote2 Assisted-by: Antigravity:gemini-3.6-flash Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-08-07Merge tag 'watchdog-for-v7.2-rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging Pull watchdog fixes from Guenter Roeck: - at91sam9_wdt: prevent timer rearm during teardown - bd96801_wdt: Fix timeout for enabled WDG - atcwdt200: Fix return value when watchdog is enabled * tag 'watchdog-for-v7.2-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: watchdog: at91sam9_wdt: prevent timer rearm during teardown watchdog: bd96801_wdt: Fix timeout for enabled WDG watchdog: atcwdt200: fix return value when watchdog is enabled
2026-08-07Merge branch ↵Jakub Kicinski
'tun-tap-vhost-net-apply-qdisc-backpressure-on-full-ptr_ring-to-reduce-tx-drops' Simon Schippers says: ==================== tun/tap & vhost-net: apply qdisc backpressure on full ptr_ring to reduce TX drops This patch series deals with tun/tap & vhost-net which drop incoming SKBs whenever their internal ptr_ring buffer is full. Instead, with this patch series, the associated netdev queue is stopped, but only when the new IFF_BACKPRESSURE flag is set and a qdisc is attached. Without the flag, or if no qdisc is present, the existing behavior is preserved. The XDP transmit path is not affected. This patch series touches tun/tap and vhost-net, as they share common logic and must be updated together. Modifying only one of them would break the other. By applying proper backpressure, this change allows the connected qdisc to operate correctly, as reported in [1], and significantly improves performance in real-world scenarios, as demonstrated in our paper [2]. For example, we observed a 36% TCP throughput improvement for an OpenVPN connection between Germany and the USA. The previous version of this work was applied and then reverted in 7.2, because the backpressure was unconditional: it caused a significant throughput drop in an IPv6 multicast testcase with multiple iperf3 TCP threads sending on Brett Sheffield's librecast testbed [3]. This version therefore makes the behavior opt-in via IFF_BACKPRESSURE from the very first patch, so that a tun/tap device which does not set the flag behaves exactly as before. The series is ordered so that no patch changes how packets are handled unless the flag is set: - Patch 1 adds the flag only. It has no effect yet: TUNSETIFF silently masks it off, as it does for any flag outside TUN_FEATURES, until patch 5 adds it there. - Patches 2 and 3 add the consumer side, which wakes a stopped netdev queue. __tun_wake_queue() returns early unless IFF_BACKPRESSURE is set, and no queue is stopped at this point anyway. - Patch 4 is a pure ptr_ring refactor required by patch 5. - Patch 5 adds the queue stopping, gated on IFF_BACKPRESSURE, together with the wake needed when the flag is cleared again, and only there is the flag added to TUN_FEATURES. That way no intermediate commit changes the behavior of an existing tun/tap user beyond the added checks, and bisecting inside the series can not hit the regression that led to the revert. [1] https://unix.stackexchange.com/questions/762935/traffic-shaping-ineffective-on-tun-device [2] https://cni.etit.tu-dortmund.de/storages/cni-etit/r/Research/Publications/2025/Gebauer_2025_VTCFall/Gebauer_VTCFall2025_AuthorsVersion.pdf [3] https://lore.kernel.org/netdev/akVnoOYQOrt8k-Gu@karahi.librecast.net/ ==================== Link: https://patch.msgid.link/20260803183641.96882-1-simon.schippers@tu-dortmund.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-07tun/tap & vhost-net: stop tail-drop when IFF_BACKPRESSURE is setSimon Schippers
This commit prevents tail-drop when IFF_BACKPRESSURE is set, a qdisc is present and the ptr_ring becomes full. Once the ring reaches capacity after a produce attempt, the netdev queue is stopped instead of dropping subsequent packets. Without the flag, or if no qdisc is present, the previous tail-drop behavior is preserved. IFF_BACKPRESSURE is added to TUN_FEATURES here and not in the patch that defines it, so that TUNSETIFF honours the flag only once the implementation behind it is complete. The unconditional version of this behavior was reverted because it caused a significant throughput drop in an IPv6 multicast testcase on Brett Sheffield's librecast testbed [1]: with 8 iperf3 TCP threads sending, the throughput dropped from 13.5 Gbit/s to 9.13 Gbit/s. This is why the queue stopping is now gated on IFF_BACKPRESSURE. If producing an entry fails anyway due to a race, tun_net_xmit() drops the packet. Such rare races are expected because LLTX is enabled and the transmit path operates without the usual locking. The queue state is only touched while the device is running. The stop itself would be harmless during teardown, as tun_net_close() sets the same bit, but the re-check below it wakes the queue again and must not clear that stop. A later TUNSETIFF can clear the flag again while the device has at most one queue. Past that point tun_set_iff() returns before it writes tun->flags, which is how it already treats every other TUN_FEATURES bit. For the case where the flag does change, tun_set_iff() calls tun_force_wake_queue() for the attached tfiles, so that no queue stays stopped without a consumer that would wake it. The __tun_wake_queue() function of the consumer races with the producer for waking/stopping the netdev queue, which could result in a stalled queue. Therefore, an smp_mb__after_atomic() is introduced that pairs with the smp_mb() of the consumer. It follows the principle of store buffering described in tools/memory-model/Documentation/recipes.txt: - The producer in tun_net_xmit() first sets __QUEUE_STATE_DRV_XOFF, followed by an smp_mb__after_atomic() (= smp_mb()), and then reads the ring with __ptr_ring_check_produce(). - The consumer in __tun_wake_queue() first writes zero to the ring in __ptr_ring_consume(), followed by an smp_mb(), and then reads the queue status with netif_tx_queue_stopped(). => Following the aforementioned principle, it is impossible for the producer to see a full ring (and therefore not wake the queue on the re-check) while the consumer simultaneously fails to see a stopped queue (and therefore also does not wake it). tun_net_xmit() holds only the producer_lock and can not reset cons_cnt, which the consumer_lock protects, so the wake on the re-check leaves stale credit behind. That is accepted as best-effort, the re-check rarely succeeds and the next drain corrects the count. The documentation in tuntap.rst is updated accordingly. Benchmarks: My own benchmarks show a slight regression in raw transmission performance when using two sending threads. Packet loss also occurs only in the two-thread sending case; no packet loss was observed with a single sending thread. Test setup: AMD Ryzen 5 5600X at 4.3 GHz, 3200 MHz RAM, isolated QEMU threads; Average over 50 runs @ 100,000,000 packets. SRSO and spectre v2 mitigations disabled. Note for tap+vhost-net: XDP drop program active in VM -> ~2.5x faster; slower for tap due to more syscalls (high utilization of entry_SYSRETQ_unsafe_stack in perf) +--------------------------+--------------+----------------+----------+ | 1 thread | Stock | Patched with | diff | | sending | | fq_codel qdisc | | +------------+-------------+--------------+----------------+----------+ | TAP | Received | 1.132 Mpps | 1.123 Mpps | -0.8% | | +-------------+--------------+----------------+----------+ | | Lost/s | 3.765 Mpps | 0 pps | | +------------+-------------+--------------+----------------+----------+ | TAP | Received | 3.857 Mpps | 3.901 Mpps | +1.1% | | +-------------+--------------+----------------+----------+ | +vhost-net | Lost/s | 0.802 Mpps | 0 pps | | +------------+-------------+--------------+----------------+----------+ +--------------------------+--------------+----------------+----------+ | 2 threads | Stock | Patched with | diff | | sending | | fq_codel qdisc | | +------------+-------------+--------------+----------------+----------+ | TAP | Received | 1.115 Mpps | 1.081 Mpps | -3.0% | | +-------------+--------------+----------------+----------+ | | Lost/s | 8.490 Mpps | 391 pps | | +------------+-------------+--------------+----------------+----------+ | TAP | Received | 3.664 Mpps | 3.555 Mpps | -3.0% | | +-------------+--------------+----------------+----------+ | +vhost-net | Lost/s | 5.330 Mpps | 938 pps | | +------------+-------------+--------------+----------------+----------+ [1] https://lore.kernel.org/netdev/akVnoOYQOrt8k-Gu@karahi.librecast.net/ Co-developed-by: Tim Gebauer <tim.gebauer@tu-dortmund.de> Signed-off-by: Tim Gebauer <tim.gebauer@tu-dortmund.de> Signed-off-by: Simon Schippers <simon.schippers@tu-dortmund.de> Link: https://lore.kernel.org/netdev/akVnoOYQOrt8k-Gu@karahi.librecast.net/ Link: https://patch.msgid.link/20260803183641.96882-6-simon.schippers@tu-dortmund.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-07ptr_ring: move free-space check into separate helperSimon Schippers
This patch moves the check for available free space for a new entry into a separate function. Existing callers that only check for a non-zero return value are unaffected. __ptr_ring_produce() now returns -EINVAL for a zero-size ring and -ENOSPC when full, whereas before both cases returned -ENOSPC. The new helper allows callers to determine in advance whether a single subsequent __ptr_ring_produce() call will succeed. This information can, for example, be used to temporarily stop producing until __ptr_ring_check_produce() indicates that space is available again. The return values are documented above the helper, as a caller that waits for space must distinguish the transient -ENOSPC from the permanent -EINVAL. Co-developed-by: Tim Gebauer <tim.gebauer@tu-dortmund.de> Signed-off-by: Tim Gebauer <tim.gebauer@tu-dortmund.de> Signed-off-by: Simon Schippers <simon.schippers@tu-dortmund.de> Link: https://patch.msgid.link/20260803183641.96882-5-simon.schippers@tu-dortmund.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-07vhost-net: wake queue of tun/tap after ptr_ring consumeSimon Schippers
Add tun_wake_queue() to tun.c and export it for use by vhost-net. The function validates that the file belongs to a device implemented by drivers/net/tun.c, in IFF_TUN as well as in IFF_TAP mode, and that the tfile exists, dereferences the tun_struct under RCU, and delegates to __tun_wake_queue(). vhost_net_buf_produce() now calls tun_wake_queue() after a successful batched consume of the ring to allow the netdev subqueue to be woken up. The point is to allow the queue to be stopped when it gets full, which is required for traffic shaping, implemented by the following "stop tail-drop when IFF_BACKPRESSURE is set". As __tun_wake_queue() returns early unless IFF_BACKPRESSURE is set, a tun/tap device that does not opt in only pays for the added check. macvtap and ipvtap rings, which get_tap_ptr_ring() accepts too, are unaffected: their producer is the tap_handle_frame() rx_handler and not ndo_start_xmit, so stopping a netdev TX queue would not hold it back. drivers/net/tap.c has no netdev_ops of its own either. No tap_wake_queue() is needed. cons_cnt and the wake decision are best-effort and are not reverted by ptr_ring_unconsume(), so vhost_net_buf_unproduce() can leave the subqueue woken over a full ring. The producer re-stops it on the next packet, and that path only runs from vhost_net_stop_vq() and vhost_net_set_backend(), when the consumer is going away, so a stopped queue is the correct end state rather than a stall. Co-developed-by: Tim Gebauer <tim.gebauer@tu-dortmund.de> Signed-off-by: Tim Gebauer <tim.gebauer@tu-dortmund.de> Signed-off-by: Simon Schippers <simon.schippers@tu-dortmund.de> Link: https://patch.msgid.link/20260803183641.96882-4-simon.schippers@tu-dortmund.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-07tun/tap: add ptr_ring consume helper with netdev queue wakeupSimon Schippers
Introduce tun_ring_consume() that wraps ptr_ring_consume() and calls __tun_wake_queue(). The latter wakes the stopped netdev subqueue once half of the ring capacity has been consumed, tracked via the new cons_cnt field in tun_file. As a safety net, the queue is also woken on the last consumed entry if it leaves the ring empty. The point is to allow the queue to be stopped when it gets full, which is required for traffic shaping, implemented by the following "stop tail-drop when IFF_BACKPRESSURE is set". __tun_wake_queue() returns early unless IFF_BACKPRESSURE is set, so for a tun/tap device that does not opt in only the added check on the consume path remains. Every site that clears __QUEUE_STATE_DRV_XOFF now checks netif_running() under a ring lock that tun_net_close() takes, so that none of them undoes its stop. The core sets it before it calls ndo_open() and clears it before it calls ndo_stop(), so it is false for exactly as long as the device is down. IFF_UP would not do, it is only cleared after ndo_stop() returns. Some implementation details: - tun_ring_recv() replaces ptr_ring_consume() with tun_ring_consume() to properly wake the queue. - __tun_wake_queue() returns early for a device that is not running, so a stop from tun_net_close() is not mistaken for backpressure, and it only wakes if the tfile still owns its slot in tun->tfiles[]. A detached tfile keeps its queue_index, which __tun_detach() may already have handed to the tfile that took over the slot. - lockdep_assert_held() enforces the documented consumer_lock precondition of __tun_wake_queue(). - __tun_detach() locks the tx_ring.consumer_lock to avoid races with the consumer on the queue_index, and that of tfile across the hand-over of the slot, which makes the ownership check above exact. - The ptr_ring_consume() call in tun_queue_purge() is not replaced with tun_ring_consume(). Instead __tun_detach() wakes the netdev queue for the ntfile taking it over, to avoid a possible stall. The queue is only woken if the ring of the ntfile is empty, as otherwise the consumer wakes it after consuming the remaining entries. This does not matter for tun_detach_all(), as it is called during device teardown and no tfile takes over any queue. - That wake sits after synchronize_net() and tun_queue_purge(), so it can not be undone by a concurrent tun_net_xmit() or __tun_wake_queue(). - Ensure detached queues are woken on re-attach by calling the new tun_force_wake_queue() helper from tun_attach(), and reuse it across the existing wake paths. Unlike __tun_wake_queue() it ignores IFF_BACKPRESSURE, so a queue can not stay stopped after the flag is cleared. It does honour netif_running(), but it always clears cons_cnt, so no old count is left over when the queue is stopped again. - tun_net_close() takes and releases both ring locks of every tfile before netif_tx_stop_all_queues(), so that its stop is the last write to __QUEUE_STATE_DRV_XOFF. - The aforementioned upcoming patch explains the pairing of the smp_mb() of __tun_wake_queue(). Co-developed-by: Tim Gebauer <tim.gebauer@tu-dortmund.de> Signed-off-by: Tim Gebauer <tim.gebauer@tu-dortmund.de> Signed-off-by: Simon Schippers <simon.schippers@tu-dortmund.de> Link: https://patch.msgid.link/20260803183641.96882-3-simon.schippers@tu-dortmund.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-07tun/tap: add IFF_BACKPRESSURE flagSimon Schippers
Add the IFF_BACKPRESSURE flag to the UAPI header and to its tools/ copy. The flag has no effect yet, it is the opt-in switch for the qdisc backpressure logic added by the following patches. It is added to TUN_FEATURES only in the last patch of the series, once the implementation is complete. Until then TUNSETIFF silently masks it off, as it does for any flag outside TUN_FEATURES. Keeping the flag and its users in separate patches would either leave a window where backpressure is unconditional, or make the opt-in a later add-on. Adding the flag first lets every following patch be a no-op unless it is set. Signed-off-by: Simon Schippers <simon.schippers@tu-dortmund.de> Link: https://patch.msgid.link/20260803183641.96882-2-simon.schippers@tu-dortmund.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-07net/sched: cls_api: fix teardown of an adopted proto on insert-race lossVictor Nogueira
In tc_new_tfilter() the create branch sets tp_created = 1 before calling tcf_chain_tp_insert_unique(). When the caller loses the race (another request inserted a proto at the same chain/prio first), insert_unique() destroys the caller's own tp_new and returns the winner's proto with an extra reference. tp_created was never cleared, so the loser's errout path treated the winner's live proto as its own and called tcf_chain_tp_delete_empty() on it, silently unlinking an active classifier that the winning request already advertised via RTM_NEWTFILTER. Track the outcome of the insert step in a single tri-state variable so each errout path reacts correctly: - TP_NOT_CREATED: no proto created; pursue the old path. - TP_CREATED: proto inserted successfully; same code path as before. - TP_NOT_OWNED: New - lost the insert race; tp is another request's proto (chain ref already released by tp_new's destroy) Both errout reactions are single expressions derived from the state. This fix is motivated by the Sashiko's automated review of Patch (net/sched: cls_api: Always acquire rtnl_lock when destroying locked classifiers) [1][2]. The review identified the silent-unlink behaviour of an adopted proto's teardown when a request loses the tcf_chain_tp_insert_unique() race. [1] https://sashiko.dev/#/patchset/20260801125632.360365-1-jhs%40mojatatu.com [2] https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260801125632.360365-1-jhs%40mojatatu.com Fixes: 8b64678e0af8 ("net: sched: refactor tp insert/delete for concurrent execution") Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://sashiko.dev/#/patchset/20260801125632.360365-1-jhs%40mojatatu.com Closes: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260801125632.360365-1-jhs%40mojatatu.com Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by: Victor Nogueira <victor@mojatatu.com> Reported-by: TencentOS Corvus AI <corvus@tencent.com> Tested-by: Aohan Mei <henrymei@tencent.com> Link: https://patch.msgid.link/20260805134049.927864-1-victor@mojatatu.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-07Merge tag 'hwmon-for-v7.2-rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging Pull hwmon fixes from Guenter Roeck: "Various fixes, most of them fixing critical or high severity bugs reported by Sashiko. ads7828: - Fix external VREF regulator handling corsair-psu: - Fix linear11 calculation - Serialize debugfs access against hwmon - Fix possible out-of-bounds access on missing string termination ltc4282: - Fix parsing adi,current-limit-sense-microvolt - Clamp negative current limits - Avoid overflow in maximum power calculation nzxt-smart2: - Check return value of init_device() in probe PMBus core: - Fix type confusion in notification logic - Avoid race condition during probe PMBus/lm25066: - Fix PMBus coefficient calculations" * tag 'hwmon-for-v7.2-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: hwmon: (corsair-psu) Fix linear11 calculation hwmon: (corsair-psu) serialize debugfs access against hwmon hwmon: (ltc4282) Fix parsing adi,current-limit-sense-microvolt hwmon: (ltc4282) Clamp negative current limits hwmon: (ltc4282) Avoid overflow in maximum power calculation hwmon: (ads7828) Fix external VREF regulator handling hwmon: (corsair-psu) fix possible out-of-bounds access on missing string termination hwmon: (pmbus/lm25066) Fix PMBus coefficient calculations hwmon: (nzxt-smart2) Check return value of init_device() in probe hwmon: (pmbus) Fix type confusion in notification logic hwmon: (pmbus/core) Avoid race condition during probe
2026-08-07Merge branch 'fix-skb-length-accounting-after-xdp-frag-adjustment'Jakub Kicinski
Sun Jian says: ==================== fix skb length accounting after XDP frag adjustment This series fixes skb length accounting after an XDP program adjusts its fragment area, in both the generic XDP path (net/core/dev.c) and the veth native path (drivers/net/veth.c). When the fragment area is resized, skb->len and skb->data_len can go out of sync, and in the reproduced UDP receive path this leaked skb_shared_info contents (including a kernel pointer) to userspace while truncating real payload. ==================== Link: https://patch.msgid.link/20260804054040.613675-1-sun.jian.kdev@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-23 15:59:13 +0000