summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-04-11dt-bindings: hwmon/pmbus: Add Infineon XDP720Ashish Yadav
Add documentation for the device tree binding of the XDP720 eFuse. Signed-off-by: Ashish Yadav <ashish.yadav@infineon.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20260410070154.3313-2-Ashish.Yadav@infineon.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-04-11hwmon: add support for MCP998XVictor Duicu
Add driver for Microchip MCP998X/33 and MCP998XD/33D Multichannel Automotive Temperature Monitor Family. Signed-off-by: Victor Duicu <victor.duicu@microchip.com> Link: https://lore.kernel.org/r/20260403-add-mcp9982-hwmon-v12-2-b3bfb26ff136@microchip.com [groeck: Add missing break; to avoid build warning] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-04-10pstore/ftrace: Factor KASLR offset in the core kernel instruction addressesGuilherme G. Piccoli
The pstore ftrace frontend works by purely collecting the instruction address, saving it on the persistent area through the backend and when the log is read, on next boot for example, the address is then resolved by using the regular printk symbol lookup (%pS for example). Problem: if we are running a relocatable kernel with KASLR enabled, this is a recipe for failure in the symbol resolution on next boots, since the addresses are offset'ed by the KASLR address. So, naturally the way to go is factor the KASLR address out of instruction address collection, and adding the fresh offset when resolving the symbol on future boots. Problem #2: modules also have varying addresses that float based on module base address and potentially the module ordering in memory, meaning factoring KASLR offset for them is useless. So, let's hereby only take KASLR offset into account for core kernel addresses, leaving module ones as is. And we have yet a 3rd complexity: not necessarily the check range for core kernel addresses holds true on future boots, since the module base address will vary. With that, the choice was to mark the addresses as being core vs module based on its MSB. And with that... ...we have the 4th challenge here: for some "simple" architectures, the CPU number is saved bit-encoded on the instruction pointer, to allow bigger timestamps - this is set through the PSTORE_CPU_IN_IP define for such architectures. Hence, the approach here is to skip such architectures (at least in a first moment). Finished? No. On top of all previous complexities, we have one extra pain point: kaslr_offset() is inlined and fully "resolved" at boot-time, after kernel decompression, through ELF relocation mechanism. Once the offset is known, it's patched to the kernel text area, wherever it is used. The mechanism, and its users, are only built-in - incompatible with module usage. Though there are possibly some hacks (as computing the offset using some kallsym lookup), the choice here is to restrict this optimization to the (hopefully common) case of CONFIG_PSTORE=y. TL;DR: let's factor KASLR offsets on pstore/ftrace for core kernel addresses, only when PSTORE is built-in and leaving module addresses out, as well as architectures that define PSTORE_CPU_IN_IP. Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com> Link: https://patch.msgid.link/20260410205848.2607169-1-gpiccoli@igalia.com Signed-off-by: Kees Cook <kees@kernel.org>
2026-04-11Merge branch 'timers/urgent' into timers/coreThomas Gleixner
to resolve the conflict with urgent fixes.
2026-04-10Merge branch 'use-kmalloc_nolock-universally-in-bpf-local-storage'Alexei Starovoitov
Amery Hung says: ==================== Use kmalloc_nolock() universally in BPF local storage Socket local storage did not convert to use kmalloc_nolock() since there were observable performance degredation due to kfree_nolock() hitting the slow path and the lack of kfree_rcu()-like batching freeing. Now that these concern were addressed in slub, convert all remaining local storage flavors to use kmalloc_nolock(). v1 -> v2: - Fix build (CI, Alexei) ==================== Link: https://patch.msgid.link/20260411015419.114016-1-ameryhung@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-04-10bpf: Remove gfp_flags plumbing from bpf_local_storage_update()Amery Hung
Remove the check that rejects sleepable BPF programs from doing BPF_ANY/BPF_EXIST updates on local storage. This restriction was added in commit b00fa38a9c1c ("bpf: Enable non-atomic allocations in local storage") because kzalloc(GFP_KERNEL) could sleep inside local_storage->lock. This is no longer a concern: all local storage allocations now use kmalloc_nolock() which never sleeps. In addition, since kmalloc_nolock() only accepts __GFP_ACCOUNT, __GFP_ZERO and __GFP_NO_OBJ_EXT, the gfp_flags parameter plumbing from bpf_*_storage_get() to bpf_local_storage_update() becomes dead code. Remove gfp_flags from bpf_selem_alloc(), bpf_local_storage_alloc() and bpf_local_storage_update(). Drop the hidden 5th argument from bpf_*_storage_get helpers, and remove the verifier patching that injected GFP_KERNEL/GFP_ATOMIC into the fifth argument. Signed-off-by: Amery Hung <ameryhung@gmail.com> Link: https://lore.kernel.org/r/20260411015419.114016-4-ameryhung@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-04-10bpf: Use kmalloc_nolock() universally in local storageAmery Hung
Switch to kmalloc_nolock() universally in local storage. Socket local storage didn't move to kmalloc_nolock() when BPF memory allocator was replaced by it for performance reasons. Now that kfree_rcu() supports freeing memory allocated by kmalloc_nolock(), we can move the remaining local storages to use kmalloc_nolock() and cleanup the cluttered free paths. Use kfree() instead of kfree_nolock() in bpf_selem_free_trace_rcu() and bpf_local_storage_free_trace_rcu(). Both callbacks run in process context where spinning is allowed, so kfree_nolock() is unnecessary. Benchmark: ./bench -p 1 local-storage-create --storage-type socket \ --batch-size {16,32,64} The benchmark is a microbenchmark stress-testing how fast local storage can be created. There is no measurable throughput change for socket local storage after switching from kzalloc() to kmalloc_nolock(). Socket local storage batch creation speed diff --------------- ---- ------------------ ---- Baseline 16 433.9 ± 0.6 k/s 32 434.3 ± 1.4 k/s 64 434.2 ± 0.7 k/s After 16 439.0 ± 1.9 k/s +1.2% 32 437.3 ± 2.0 k/s +0.7% 64 435.8 ± 2.5k/s +0.4% Also worth noting that the baseline got a 5% throughput boost when sheaf replaces percpu partial slab recently [0]. [0] https://lore.kernel.org/bpf/20260123-sheaves-for-all-v4-0-041323d506f7@suse.cz/ Signed-off-by: Amery Hung <ameryhung@gmail.com> Link: https://lore.kernel.org/r/20260411015419.114016-3-ameryhung@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-04-10selftests/bpf: Remove kmalloc tracing from local storage create benchAmery Hung
Remove the raw_tp/kmalloc BPF program and its associated reporting from the local storage create benchmark. The kmalloc count per create is not a useful metric as different code paths use different allocators (e.g. kmalloc_nolock vs kzalloc), introducing noise that makes the number hard to interpret. Keep total_creates in the summary output as it is useful for normalizing perf statistics collected alongside the benchmark. Signed-off-by: Amery Hung <ameryhung@gmail.com> Link: https://lore.kernel.org/r/20260411015419.114016-2-ameryhung@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-04-10sched_ext: Drop spurious warning on kick during scheduler disableTejun Heo
kick_cpus_irq_workfn() warns when scx_kick_syncs is NULL, but this can legitimately happen when a BPF timer or other kick source races with free_kick_syncs() during scheduler disable. Drop the pr_warn_once() and add a comment explaining the race. Signed-off-by: Tejun Heo <tj@kernel.org> Reviewed-by: Zhao Mengmeng <zhaomengmeng@kylinos.cn>
2026-04-10smb: client: get rid of d_drop()+d_add()Paulo Alcantara
Replace d_drop()+d_add() in cifs_tmpfile() and cifs_create() with d_instantiate(), and in cifs_atomic_open() with d_splice_alias() if in-lookup, otherwise d_instantiate(). Reported-by: Al Viro <viro@zeniv.linux.org.uk> Closes: https://lore.kernel.org/r/20260408065719.GF3836593@ZenIV Signed-off-by: Paulo Alcantara (Red Hat) <pc@manguebit.org> Cc: David Howells <dhowells@redhat.com> Cc: NeilBrown <neilb@ownmail.net> Cc: linux-fsdevel@vger.kernel.org Cc: linux-cifs@vger.kernel.org Signed-off-by: Steve French <stfrench@microsoft.com>
2026-04-10selftests/bpf: Add test for add_const base_id consistencyDaniel Borkmann
Add a test to verifier_linked_scalars that exercises the base_id consistency check for BPF_ADD_CONST linked scalars during state pruning. With the fix, pruning fails and the verifier discovers the true branch's R3 is too wide for the stack access. # LDLIBS=-static PKG_CONFIG='pkg-config --static' ./vmtest.sh -- ./test_progs -t verifier_linked_scalars [...] #613/22 verifier_linked_scalars/scalars_stale_delta_from_cleared_id:OK #613/23 verifier_linked_scalars/scalars_stale_delta_from_cleared_id_alu32:OK #613/24 verifier_linked_scalars/linked scalars: add_const base_id must be consistent for pruning:OK #613 verifier_linked_scalars:OK Summary: 1/24 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/r/20260410232651.559778-2-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-04-10bpf: Enforce regsafe base id consistency for BPF_ADD_CONST scalarsDaniel Borkmann
When regsafe() compares two scalar registers that both carry BPF_ADD_CONST, check_scalar_ids() maps their full compound id (aka base | BPF_ADD_CONST flag) as one idmap entry. However, it never verifies that the underlying base ids, that is, with the flag stripped are consistent with existing idmap mappings. This allows construction of two verifier states where the old state has R3 = R2 + 10 (both sharing base id A) while the current state has R3 = R4 + 10 (base id C, unrelated to R2). The idmap creates two independent entries: A->B (for R2) and A|flag->C|flag (for R3), without catching that A->C conflicts with A->B. State pruning then incorrectly succeeds. Fix this by additionally verifying base ID mapping consistency whenever BPF_ADD_CONST is set: after mapping the compound ids, also invoke check_ids() on the base IDs (flag bits stripped). This ensures that if A was already mapped to B from comparing the source register, any ADD_CONST derivative must also derive from B, not an unrelated C. Fixes: 98d7ca374ba4 ("bpf: Track delta between "linked" registers.") Reported-by: STAR Labs SG <info@starlabs.sg> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/r/20260410232651.559778-1-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-04-10Merge tag 'riscv-for-linus-v7.0-rc8' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V updates from Paul Walmsley: "Before v7.0 is released, fix a few issues with the CFI patchset, merged earlier in v7.0-rc, that primarily affect interfaces to non-kernel code: - Improve the prctl() interface for per-task indirect branch landing pad control to expand abbreviations and to resemble the speculation control prctl() interface - Expand the "LP" and "SS" abbreviations in the ptrace uapi header file to "branch landing pad" and "shadow stack", to improve readability - Fix a typo in a CFI-related macro name in the ptrace uapi header file - Ensure that the indirect branch tracking state and shadow stack state are unlocked immediately after an exec() on the new task so that libc subsequently can control it - While working in this area, clean up the kernel-internal, cross-architecture prctl() function names by expanding the abbreviations mentioned above" * tag 'riscv-for-linus-v7.0-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: prctl: cfi: change the branch landing pad prctl()s to be more descriptive riscv: ptrace: cfi: expand "SS" references to "shadow stack" in uapi headers prctl: rename branch landing pad implementation functions to be more explicit riscv: ptrace: expand "LP" references to "branch landing pads" in uapi headers riscv: cfi: clear CFI lock status in start_thread() riscv: ptrace: cfi: fix "PRACE" typo in uapi header
2026-04-10Merge tag 'drm-fixes-2026-04-11' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds
Pull drm fixes from Dave Airlie: "Last set of fixes, a few vc4, and i915, one xe and one ethosu Kconfig fix. xe: - Fix HW engine idleness unit conversion i915: - Drop check for changed VM in EXECBUF - Fix refcount underflow race in intel_engine_park_heartbeat - Do not use pipe_src as borders for SU area in PSR vc4: - runtime pm reference fix - memory leak fixes - locking fix ethosu: - make ARM only" * tag 'drm-fixes-2026-04-11' of https://gitlab.freedesktop.org/drm/kernel: drm/i915/gem: Drop check for changed VM in EXECBUF drm/i915/gt: fix refcount underflow in intel_engine_park_heartbeat drm/xe: Fix bug in idledly unit conversion drm/i915/psr: Do not use pipe_src as borders for SU area accel: ethosu: Add hardware dependency hint drm/vc4: Protect madv read in vc4_gem_object_mmap() with madv_lock drm/vc4: Fix a memory leak in hang state error path drm/vc4: Fix memory leak of BO array in hang state drm/vc4: Release runtime PM reference after binding V3D
2026-04-10iavf: fix kernel-doc comment style in iavf_ethtool.cAleksandr Loktionov
iavf_ethtool.c contains 31 kernel-doc comment blocks using the legacy `**/` terminator instead of the correct single `*/`. Two function headers also use a colon separator (`iavf_get_channels:`, `iavf_set_channels:`) instead of the ` - ` dash required by kernel-doc. Additionally several comments embed their return-value descriptions in the body paragraph, producing `scripts/kernel-doc -Wreturn` warnings. Void functions that incorrectly say "Returns ..." are also rephrased. Fix all issues across the full file: - Replace every `**/` terminator with `*/`. - Change `function_name:` doc headers to `function_name -`. - Move inline "Returns ..." sentences into dedicated `Return:` sections for non-void functions (iavf_get_msglevel, iavf_get_rxnfc, iavf_set_channels, iavf_get_rxfh_key_size, iavf_get_rxfh_indir_size, iavf_get_rxfh, iavf_set_rxfh). - Rephrase body descriptions in void functions that incorrectly said "Returns ..." (iavf_get_drvinfo, iavf_get_ringparam, iavf_get_coalesce). - Remove boilerplate body text for iavf_get_rxfh_key_size and iavf_get_rxfh_indir_size; the `Return:` line now conveys the same information without the vague "Returns the table size." sentence. Suggested-by: Anthony L. Nguyen <anthony.l.nguyen@intel.com> Suggested-by: Leszek Pepiak <leszek.pepiak@intel.com> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Breno Leitao <leitao@debian.org> Reviewed-by: Joe Damato <joe@dama.to> Link: https://patch.msgid.link/20260409093020.3808687-1-aleksandr.loktionov@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-10net: airoha: Fix FE_PSE_BUF_SET configuration if PPE2 is availableLorenzo Bianconi
airoha_fe_set routine is used to set specified bits to 1 in the selected register. In the FE_PSE_BUF_SET case this can due to a overestimation of the required buffers for I/O queues since we can miss to set some bits of PSE_ALLRSV_MASK subfield to 0. Fix the issue relying on airoha_fe_rmw routine instead. Fixes: 8e38e08f2c560 ("net: airoha: fix PSE memory configuration in airoha_fe_pse_ports_init()") Tested-by: Xuegang Lu <xuegang.lu@airoha.com> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20260408-airoha-reg_fe_pse_buf_set-v1-1-0c4fa8f4d1d9@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-10Merge branch 'net-dsa-mxl862xx-vlan-support-and-minor-improvements'Jakub Kicinski
Daniel Golle says: ==================== net: dsa: mxl862xx: VLAN support and minor improvements This series adds VLAN offloading to the mxl862xx DSA driver along with two minor improvements to port setup and bridge configuration. VLAN support uses a hybrid architecture combining the Extended VLAN engine for PVID insertion and tag stripping with the VLAN Filter engine for per-port VID membership, both drawing from shared 1024-entry hardware pools partitioned across user ports at probe time. ==================== Link: https://patch.msgid.link/cover.1775581804.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-10net: dsa: mxl862xx: implement VLAN functionalityDaniel Golle
Add VLAN support using both the Extended VLAN (EVLAN) engine and the VLAN Filter (VF) engine in a hybrid architecture that allows a higher number of VIDs than either engine could achieve alone. The VLAN Filter engine handles per-port VID membership checks with discard-unmatched semantics. The Extended VLAN engine handles PVID insertion on ingress (via fixed catchall rules) and tag stripping on egress (2 rules per untagged VID). Tagged-only VIDs need no EVLAN egress rules at all, so they consume only a VF entry. Both engines draw from shared 1024-entry hardware pools. The VF pool is divided equally among user ports for VID membership, while the EVLAN pool is partitioned into small fixed-size ingress blocks (7 entries of catchall rules per port) and fixed-size egress blocks for tag stripping. With 5 user ports this yields up to 204 VIDs per port (limited by VF), of which up to 98 can be untagged (limited by EVLAN egress budget). With 9 user ports the numbers are 113 total and 53 untagged. Wire up .port_vlan_add, .port_vlan_del, and .port_vlan_filtering. Reprogram all EVLAN rules when the PVID or filtering mode changes. Detach blocks from the bridge port before freeing them on bridge leave to satisfy the firmware's internal refcount. Future optimizations could increase VID capacity by dynamically sizing the egress EVLAN blocks based on actual per-port untagged VID counts rather than worst-case pre-allocation, or by sharing EVLAN egress and VLAN Filter blocks across ports with identical VID sets. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Link: https://patch.msgid.link/9be29637675342b109a85fa08f5378800d9f7b78.1775581804.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-10net: dsa: mxl862xx: don't skip early bridge port configurationDaniel Golle
mxl862xx_bridge_port_set() is currently guarded by the mxl8622_port->setup_done flag, as the early call to mxl862xx_bridge_port_set() from mxl862xx_port_stp_state_set() would otherwise cause a NULL-pointer dereference on unused ports which don't have dp->cpu_dp despite not being a CPU port. Using the setup_done flag (which is never set for unused ports), however, also prevents mxl862xx_bridge_port_set() from configuring user ports' single-port bridges early, which was unintended. Fix this by returning early from mxl862xx_bridge_port_set() in case dsa_port_is_unused(). Fixes: 340bdf984613c ("net: dsa: mxl862xx: implement bridge offloading") Signed-off-by: Daniel Golle <daniel@makrotopia.org> Link: https://patch.msgid.link/15962aac29ebe0a6eb77565451acff880c41ef33.1775581804.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-10net: dsa: mxl862xx: reject DSA_PORT_TYPE_DSADaniel Golle
DSA links aren't supported by the mxl862xx driver. Instead of returning early from .port_setup when called for DSA_PORT_TYPE_DSA ports rather return -EOPNOTSUPP and show an error message. The desired side-effect is that the framework will switch the port to DSA_PORT_TYPE_UNUSED, so we can stop caring about DSA_PORT_TYPE_DSA in all other places. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Link: https://patch.msgid.link/b686f3a22d8a6e7d470e7aa98da811a996a229b9.1775581804.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-10Merge branch 'net-bridge-add-stp_mode-attribute-for-stp-mode-selection'Jakub Kicinski
Andy Roulin says: ==================== net: bridge: add stp_mode attribute for STP mode selection The bridge-stp usermode helper is currently restricted to the initial network namespace, preventing userspace STP daemons like mstpd from operating on bridges in other namespaces. Since commit ff62198553e4 ("bridge: Only call /sbin/bridge-stp for the initial network namespace"), bridges in non-init namespaces silently fall back to kernel STP with no way to request userspace STP. This series adds a new IFLA_BR_STP_MODE bridge attribute that allows explicit per-bridge control over STP mode selection. Three modes are supported: - auto (default): existing behavior, try /sbin/bridge-stp in init_net, fall back to kernel STP otherwise - user: directly enable BR_USER_STP without invoking the helper, works in any network namespace - kernel: directly enable BR_KERNEL_STP without invoking the helper The user and kernel modes bypass call_usermodehelper() entirely, addressing the security concerns discussed at [1]. Userspace is responsible for ensuring an STP daemon manages the bridge, rather than relying on the kernel to invoke /sbin/bridge-stp. Patch 1 adds the kernel support. The mode can only be changed while STP is disabled and is processed before IFLA_BR_STP_STATE in br_changelink() so both can be set atomically in a single netlink message. Patch 2 adds documentation for the new attribute in the bridge docs. Patch 3 adds a selftest with 9 test cases. The test requires iproute2 with IFLA_BR_STP_MODE support and can be run with virtme-ng: vng --run arch/x86/boot/bzImage --skip-modules \ --overlay-rwdir /sbin --overlay-rwdir /tmp --overlay-rwdir /bin \ --exec 'cp /path/to/iproute2-next/ip/ip /bin/ip && \ cd tools/testing/selftests/net && \ bash bridge_stp_mode.sh' iproute2 support can be found here [2]. [1] https://lore.kernel.org/netdev/565B7F7D.80208@nod.at/ [2] https://github.com/aroulin/iproute2-next/tree/bridge-stp-mode ==================== Link: https://patch.msgid.link/20260405205224.3163000-1-aroulin@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-10selftests: net: add bridge STP mode selection testAndy Roulin
Add a selftest for the IFLA_BR_STP_MODE bridge attribute that verifies: 1. stp_mode defaults to auto on new bridges 2. stp_mode can be toggled between user, kernel, and auto 3. Changing stp_mode while STP is active is rejected with -EBUSY 4. Re-setting the same stp_mode while STP is active succeeds 5. stp_mode user in a network namespace yields userspace STP (stp_state=2) 6. stp_mode kernel forces kernel STP (stp_state=1) 7. stp_mode auto in a netns preserves traditional fallback to kernel STP 8. stp_mode and stp_state can be set atomically in a single message 9. stp_mode persists across STP disable/enable cycles Test 5 is the key use case: it demonstrates that userspace STP can now be enabled in non-init network namespaces by setting stp_mode to user before enabling STP. Test 8 verifies the atomic usage pattern where both attributes are set in a single netlink message, which is supported because br_changelink() processes IFLA_BR_STP_MODE before IFLA_BR_STP_STATE. The test gracefully skips if the installed iproute2 does not support the stp_mode attribute. Assisted-by: Claude:claude-opus-4-6 Reviewed-by: Ido Schimmel <idosch@nvidia.com> Acked-by: Nikolay Aleksandrov <nikolay@nvidia.com> Signed-off-by: Andy Roulin <aroulin@nvidia.com> Link: https://patch.msgid.link/20260405205224.3163000-4-aroulin@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-10docs: net: bridge: document stp_mode attributeAndy Roulin
Add documentation for the IFLA_BR_STP_MODE bridge attribute in the "User space STP helper" section of the bridge documentation. Reference the BR_STP_MODE_* values via kernel-doc and describe the use case for network namespace environments. Reviewed-by: Ido Schimmel <idosch@nvidia.com> Acked-by: Nikolay Aleksandrov <nikolay@nvidia.com> Signed-off-by: Andy Roulin <aroulin@nvidia.com> Link: https://patch.msgid.link/20260405205224.3163000-3-aroulin@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-10net: bridge: add stp_mode attribute for STP mode selectionAndy Roulin
The bridge-stp usermode helper is currently restricted to the initial network namespace, preventing userspace STP daemons (e.g. mstpd) from operating on bridges in other network namespaces. Since commit ff62198553e4 ("bridge: Only call /sbin/bridge-stp for the initial network namespace"), bridges in non-init namespaces silently fall back to kernel STP with no way to use userspace STP. Add a new bridge attribute IFLA_BR_STP_MODE that allows explicit per-bridge control over STP mode selection: BR_STP_MODE_AUTO (default) - Existing behavior: invoke the /sbin/bridge-stp helper in init_net only; fall back to kernel STP if it fails or in non-init namespaces. BR_STP_MODE_USER - Directly enable userspace STP (BR_USER_STP) without invoking the helper. Works in any network namespace. Userspace is responsible for ensuring an STP daemon manages the bridge. BR_STP_MODE_KERNEL - Directly enable kernel STP (BR_KERNEL_STP) without invoking the helper. The mode can only be changed while STP is disabled, or set to the same value (-EBUSY otherwise). IFLA_BR_STP_MODE is processed before IFLA_BR_STP_STATE in br_changelink(), so both can be set atomically in a single netlink message. The mode can also be changed in the same message that disables STP. The stp_mode struct field is u8 since all possible values fit, while NLA_U32 is used for the netlink attribute since it occupies the same space in the netlink message as NLA_U8. A new stp_helper_active boolean tracks whether the /sbin/bridge-stp helper was invoked during br_stp_start(), so that br_stp_stop() only calls the helper for stop when it was called for start. This avoids calling the helper asymmetrically when stp_mode changes between start and stop. Suggested-by: Ido Schimmel <idosch@nvidia.com> Assisted-by: Claude:claude-opus-4-6 Reviewed-by: Ido Schimmel <idosch@nvidia.com> Acked-by: Nikolay Aleksandrov <nikolay@nvidia.com> Signed-off-by: Andy Roulin <aroulin@nvidia.com> Link: https://patch.msgid.link/20260405205224.3163000-2-aroulin@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-10Merge branch 'add-selftests-for-ntuple-nfc-rules'Jakub Kicinski
Dimitri Daskalakis says: ==================== Add selftests for ntuple (NFC) rules Thoroughly testing a device's NFC implementation can be tedious. The more features a device supports, the more combinations to validate. This series aims to ease that burden, validating the most common NFC rule combinations. ==================== Link: https://patch.msgid.link/20260407164954.2977820-1-dimitri.daskalakis1@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-10selftests: drv-net: ntuple: Add dst-ip, src-port, dst-port fieldsDimitri Daskalakis
Extend the ntuple flow steering test to cover dst-ip, src-port, and dst-port fields. The test supports arbitrary combinations of the fields, for now we test src_ip/dst_ip, and src_ip/dst_ip/src_port/dst_port. The tests currently match full fields, but we can consider adding support for masked fields in the future. TAP version 13 1..24 ok 1 ntuple.queue.tcp4.src_ip ok 2 ntuple.queue.tcp4.dst_ip ok 3 ntuple.queue.tcp4.src_port ok 4 ntuple.queue.tcp4.dst_port ok 5 ntuple.queue.tcp4.src_ip.dst_ip ok 6 ntuple.queue.tcp4.src_ip.dst_ip.src_port.dst_port ok 7 ntuple.queue.udp4.src_ip ok 8 ntuple.queue.udp4.dst_ip ok 9 ntuple.queue.udp4.src_port ok 10 ntuple.queue.udp4.dst_port ok 11 ntuple.queue.udp4.src_ip.dst_ip ok 12 ntuple.queue.udp4.src_ip.dst_ip.src_port.dst_port ok 13 ntuple.queue.tcp6.src_ip ok 14 ntuple.queue.tcp6.dst_ip ok 15 ntuple.queue.tcp6.src_port ok 16 ntuple.queue.tcp6.dst_port ok 17 ntuple.queue.tcp6.src_ip.dst_ip ok 18 ntuple.queue.tcp6.src_ip.dst_ip.src_port.dst_port ok 19 ntuple.queue.udp6.src_ip ok 20 ntuple.queue.udp6.dst_ip ok 21 ntuple.queue.udp6.src_port ok 22 ntuple.queue.udp6.dst_port ok 23 ntuple.queue.udp6.src_ip.dst_ip ok 24 ntuple.queue.udp6.src_ip.dst_ip.src_port.dst_port # Totals: pass:24 fail:0 xfail:0 xpass:0 skip:0 error:0 Signed-off-by: Dimitri Daskalakis <daskald@meta.com> Link: https://patch.msgid.link/20260407164954.2977820-3-dimitri.daskalakis1@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-10selftests: drv-net: Add ntuple (NFC) flow steering testDimitri Daskalakis
Add a test for ethtool NFC (ntuple) flow steering rules. The test creates an ntuple rule matching on various flow fields and verifies that traffic is steered to the correct queue. The test forces all traffic to queue 0 via the indirection table, then installs an ntuple rule to steer select traffic to a specific queue. The test then verifies the expected number of packets is received on the queue. This test has variants for TCP/UDP over IPv4/IPv6, with rules matching the source IP. Additional match fields will be added in the next commit. TAP version 13 1..4 ok 1 ntuple.queue.tcp4.src_ip ok 2 ntuple.queue.udp4.src_ip ok 3 ntuple.queue.tcp6.src_ip ok 4 ntuple.queue.udp6.src_ip # Totals: pass:4 fail:0 xfail:0 xpass:0 skip:0 error:0 Signed-off-by: Dimitri Daskalakis <daskald@meta.com> Link: https://patch.msgid.link/20260407164954.2977820-2-dimitri.daskalakis1@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-10Merge branch 'bpf-static-stack-liveness-data-flow-analysis'Alexei Starovoitov
Eduard Zingerman says: ==================== bpf: static stack liveness data flow analysis This patch set converts current dynamic stack slot liveness tracking mechanism to a static data flow analysis. The result is used during state pruning (clean_verifier_state): to zero out dead stack slots, enabling more aggressive state equivalence and pruning. To improve analysis precision live stack slot tracking is converted to 4-byte granularity. The key ideas and the bulk of the execution behind the series belong to Alexei Starovoitov. I contributed to patch set integration with existing liveness tracking mechanism. Due to complexity of the changes the bisectability property of the patch set is not preserved. Some selftests may fail between intermediate patches of the series. Analysis consists of two passes: - A forward fixed-point analysis that tracks which frame's FP each register value is derived from, and at what byte offset. This is needed because a callee can receive a pointer to its caller's stack frame (e.g. r1 = fp-16 at the call site), then do *(u64 *)(r1 + 0) inside the callee - a cross-frame stack access that the callee's local liveness must attribute to the caller's stack. - A backward dataflow pass within each callee subprog that computes live_in = (live_out \ def) ∪ use for both local and non-local (ancestor) stack slots. The result of the analysis for callee is propagated up to the callsite. The key idea making such analysis possible is that limited and conservative argument tracking pass is sufficient to recover most of the offsets / stack pointer arguments. Changelog: v3 -> v4: liveness.c: - fill_from_stack(): correct conservative stack mask for imprecise result, instead of picking frames from pointer register (Alexei, sashiko). - spill_to_stack(): join with existing values instead of overwriting when dst has multiple offsets (cnt > 1) or imprecise offset (cnt == 0) (Alexei, sashiko). - analyze_subprog(): big change, now each analyze_subprog() is called with a fresh func_instance, once read/write marks are collected the instance is joined with the one accumulated for (callsite, depth) and update_instance() is called. This handles several issues: - Avoids stale must_write marks when same func_instance is reused by analyze_subprog() several times. - Handles potential calls multiple calls for mark_stack_write() within single instruction. (Alexei, sashiko). - analyze_subprog(): added complexity limit to avoid exponential analysis time blowup for crafted programs with lots of nested function calls (Alexei, sashiko). - the patch "bpf: record arg tracking results in bpf_liveness masks" is reinstated, it was accidentally squashed during v1->v2 transition. verifier.c: - clean_live_states() is replaced by a direct call to clean_verifier_state(), bpf_verifier_state->cleaned is dropped. verifier_live_stack.c: - added selftests for arg tracking changes. v2 -> v3: liveness.c: - record_stack_access(): handle S64_MIN (unknown read) with imprecise offset. Test case can't be created with existing helpers/kfuncs (sashiko). - fmt_subprog(): handle NULL name (subprogs without BTF info). - print_instance(): use u64 for pos/insn_pos avoid truncation (bot+bpf-ci). - compute_subprog_args(): return error if 'env->callsite_at_stack[idx] = kvmalloc_objs(...)' fails (sashiko). - clear_overlapping_stack_slots(): avoid integer promoting issues by adding explicit (int) cast (sashiko). bpf_verifier.h, verifier.c, liveness.c: - Fixes in comments and commit messages (bot+bpf-ci). v1 -> v2: liveness.c: - Removed func_instance->callsites and replaced it with explicit spine passed through analys_subprog() calls (sashiko). - Fixed BPF_LOAD_ACQ handling in arg_track_xfer: don't clear dst register tracking (sashiko). - Various error threading nits highlighted by bots (sashiko, bot+bpf-ci). - Massaged fmt_spis_mask() to be more concise (Alexei) verifier.c: - Move subprog_info[i].name assignment from add_subprog_and_kfunc to check_btf_func (sashiko, bot+bpf-ci). - Fixed inverse usage of msb/lsb halves by patch "bpf: make liveness.c track stack with 4-byte granularity" (sashiko, bot+bpf-ci). v1: https://lore.kernel.org/bpf/20260408-patch-set-v1-0-1a666e860d42@gmail.com/ v2: https://lore.kernel.org/bpf/20260409-patch-set-v2-0-651804512349@gmail.com/ v3: https://lore.kernel.org/bpf/20260410-patch-set-v3-0-1f5826dc0ef2@gmail.com/ Verification performance impact (negative % is good): ========= selftests: master vs patch-set ========= File Program Insns (A) Insns (B) Insns (DIFF) ----------------------- ------------- --------- --------- --------------- xdp_synproxy_kern.bpf.o syncookie_tc 20363 22910 +2547 (+12.51%) xdp_synproxy_kern.bpf.o syncookie_xdp 20450 23001 +2551 (+12.47%) Total progs: 4490 Old success: 2856 New success: 2856 total_insns diff min: -80.26% total_insns diff max: 12.51% 0 -> value: 0 value -> 0: 0 total_insns abs max old: 837,487 total_insns abs max new: 837,487 -85 .. -75 %: 1 -50 .. -40 %: 1 -35 .. -25 %: 1 -20 .. -10 %: 5 -10 .. 0 %: 18 0 .. 5 %: 4458 5 .. 15 %: 6 ========= scx: master vs patch-set ========= File Program Insns (A) Insns (B) Insns (DIFF) -------------- --------- --------- --------- -------------- scx_qmap.bpf.o qmap_init 20230 19022 -1208 (-5.97%) Total progs: 376 Old success: 351 New success: 351 total_insns diff min: -27.15% total_insns diff max: 0.50% 0 -> value: 0 value -> 0: 0 total_insns abs max old: 236,251 total_insns abs max new: 233,669 -30 .. -20 %: 8 -20 .. -10 %: 2 -10 .. 0 %: 21 0 .. 5 %: 345 ========= meta: master vs patch-set ========= File Program Insns (A) Insns (B) Insns (DIFF) ---------------------------------------------------------------------------- ----------------- --------- --------- ----------------- ... third-party-scx-backports-scheds-rust-scx_layered-bpf_skel_genskel-bpf.bpf.o layered_dispatch 13944 13104 -840 (-6.02%) third-party-scx-backports-scheds-rust-scx_layered-bpf_skel_genskel-bpf.bpf.o layered_dispatch 13944 13104 -840 (-6.02%) third-party-scx-gefe21962f49a-__scx_layered_bpf_skel_genskel-bpf.bpf.o layered_dispatch 13825 12985 -840 (-6.08%) third-party-scx-v1.0.16-__scx_lavd_bpf_skel_genskel-bpf.bpf.o lavd_enqueue 15501 13602 -1899 (-12.25%) third-party-scx-v1.0.16-__scx_lavd_bpf_skel_genskel-bpf.bpf.o lavd_select_cpu 19814 16231 -3583 (-18.08%) third-party-scx-v1.0.17-__scx_lavd_bpf_skel_genskel-bpf.bpf.o lavd_enqueue 15501 13602 -1899 (-12.25%) third-party-scx-v1.0.17-__scx_lavd_bpf_skel_genskel-bpf.bpf.o lavd_select_cpu 19814 16231 -3583 (-18.08%) third-party-scx-v1.0.17-__scx_layered_bpf_skel_genskel-bpf.bpf.o layered_dispatch 13976 13151 -825 (-5.90%) third-party-scx-v1.0.18-__scx_lavd_bpf_skel_genskel-bpf.bpf.o lavd_dispatch 260628 237930 -22698 (-8.71%) third-party-scx-v1.0.18-__scx_lavd_bpf_skel_genskel-bpf.bpf.o lavd_enqueue 13437 12225 -1212 (-9.02%) third-party-scx-v1.0.18-__scx_lavd_bpf_skel_genskel-bpf.bpf.o lavd_select_cpu 17744 14730 -3014 (-16.99%) third-party-scx-v1.0.19-10-6b1958477-__scx_lavd_bpf_skel_genskel-bpf.bpf.o lavd_cpu_offline 19676 18418 -1258 (-6.39%) third-party-scx-v1.0.19-10-6b1958477-__scx_lavd_bpf_skel_genskel-bpf.bpf.o lavd_cpu_online 19674 18416 -1258 (-6.39%) ... Total progs: 1540 Old success: 1492 New success: 1493 total_insns diff min: -75.83% total_insns diff max: 73.60% 0 -> value: 0 value -> 0: 0 total_insns abs max old: 434,763 total_insns abs max new: 666,036 -80 .. -70 %: 2 -55 .. -50 %: 7 -50 .. -45 %: 10 -45 .. -35 %: 4 -35 .. -25 %: 4 -25 .. -20 %: 8 -20 .. -15 %: 15 -15 .. -10 %: 11 -10 .. -5 %: 45 -5 .. 0 %: 112 0 .. 5 %: 1316 5 .. 15 %: 2 15 .. 25 %: 1 25 .. 35 %: 1 55 .. 65 %: 1 70 .. 75 %: 1 ========= cilium: master vs patch-set ========= File Program Insns (A) Insns (B) Insns (DIFF) --------------- --------------------------------- --------- --------- ---------------- bpf_host.o cil_host_policy 45801 32027 -13774 (-30.07%) bpf_host.o cil_to_netdev 100287 69042 -31245 (-31.16%) bpf_host.o tail_handle_ipv4_cont_from_host 60911 20962 -39949 (-65.59%) bpf_host.o tail_handle_ipv4_from_netdev 59735 33155 -26580 (-44.50%) bpf_host.o tail_handle_ipv6_cont_from_host 23529 17036 -6493 (-27.60%) bpf_host.o tail_handle_ipv6_from_host 11906 10303 -1603 (-13.46%) bpf_host.o tail_handle_ipv6_from_netdev 29778 23743 -6035 (-20.27%) bpf_host.o tail_handle_snat_fwd_ipv4 61616 67463 +5847 (+9.49%) bpf_host.o tail_handle_snat_fwd_ipv6 30802 22806 -7996 (-25.96%) bpf_host.o tail_ipv4_host_policy_ingress 20017 10528 -9489 (-47.40%) bpf_host.o tail_ipv6_host_policy_ingress 20693 17301 -3392 (-16.39%) bpf_host.o tail_nodeport_nat_egress_ipv4 16455 13684 -2771 (-16.84%) bpf_host.o tail_nodeport_nat_ingress_ipv4 36174 20080 -16094 (-44.49%) bpf_host.o tail_nodeport_nat_ingress_ipv6 48039 25779 -22260 (-46.34%) bpf_lxc.o tail_handle_ipv4 13765 10001 -3764 (-27.34%) bpf_lxc.o tail_handle_ipv4_cont 96891 68725 -28166 (-29.07%) bpf_lxc.o tail_handle_ipv6_cont 21809 17697 -4112 (-18.85%) bpf_lxc.o tail_ipv4_ct_egress 15949 17746 +1797 (+11.27%) bpf_lxc.o tail_nodeport_nat_egress_ipv4 16183 13432 -2751 (-17.00%) bpf_lxc.o tail_nodeport_nat_ingress_ipv4 18532 10697 -7835 (-42.28%) bpf_overlay.o tail_handle_inter_cluster_revsnat 15708 11099 -4609 (-29.34%) bpf_overlay.o tail_handle_ipv4 105672 76108 -29564 (-27.98%) bpf_overlay.o tail_handle_ipv6 15733 19944 +4211 (+26.77%) bpf_overlay.o tail_handle_snat_fwd_ipv4 19327 26468 +7141 (+36.95%) bpf_overlay.o tail_handle_snat_fwd_ipv6 20817 12556 -8261 (-39.68%) bpf_overlay.o tail_nodeport_nat_egress_ipv4 16175 12184 -3991 (-24.67%) bpf_overlay.o tail_nodeport_nat_ingress_ipv4 20760 11951 -8809 (-42.43%) bpf_wireguard.o tail_handle_ipv4 27466 28909 +1443 (+5.25%) bpf_wireguard.o tail_nodeport_nat_egress_ipv4 15937 12094 -3843 (-24.11%) bpf_wireguard.o tail_nodeport_nat_ingress_ipv4 20624 11993 -8631 (-41.85%) bpf_xdp.o tail_lb_ipv4 42673 60855 +18182 (+42.61%) bpf_xdp.o tail_lb_ipv6 87903 108585 +20682 (+23.53%) bpf_xdp.o tail_nodeport_nat_ingress_ipv4 28787 20991 -7796 (-27.08%) bpf_xdp.o tail_nodeport_nat_ingress_ipv6 207593 152012 -55581 (-26.77%) Total progs: 134 Old success: 134 New success: 134 total_insns diff min: -65.59% total_insns diff max: 42.61% 0 -> value: 0 value -> 0: 0 total_insns abs max old: 207,593 total_insns abs max new: 152,012 -70 .. -60 %: 1 -50 .. -40 %: 7 -40 .. -30 %: 9 -30 .. -25 %: 9 -25 .. -20 %: 12 -20 .. -15 %: 7 -15 .. -10 %: 14 -10 .. -5 %: 6 -5 .. 0 %: 16 0 .. 5 %: 42 5 .. 15 %: 5 15 .. 25 %: 2 25 .. 35 %: 2 35 .. 45 %: 2 ==================== Link: https://patch.msgid.link/20260410-patch-set-v4-0-5d4eecb343db@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-04-10PCI/P2PDMA: Add Google SoCs to the P2P DMA host bridge listJacob Moroni
All Google SoCs support peer-to-peer DMA between Root Ports, so add a wildcard rule to the host bridge list. Signed-off-by: Jacob Moroni <jmoroni@google.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: David Hu <xuehaohu@google.com> Reviewed-by: Logan Gunthorpe <logang@deltatee.com> Link: https://patch.msgid.link/20260409150123.3538444-2-jmoroni@google.com
2026-04-10PCI/P2PDMA: Allow wildcard Device IDs in host bridge listJacob Moroni
Currently, the pci_p2pdma_whitelist array requires an exact match for both Vendor and Device ID. Some hardware vendors support cross bridge peer-to-peer DMA across their entire silicon lineup, so add support for wildcard device IDs to avoid the need to continuously update this array. Signed-off-by: Jacob Moroni <jmoroni@google.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Logan Gunthorpe <logang@deltatee.com> Link: https://patch.msgid.link/20260409150123.3538444-1-jmoroni@google.com
2026-04-10net: hamradio: 6pack: fix uninit-value in sixpack_receive_bufMashiro Chen
sixpack_receive_buf() does not properly skip bytes with TTY error flags. The while loop iterates through the flags buffer but never advances the data pointer (cp), and passes the original count (including error bytes) to sixpack_decode(). This causes sixpack_decode() to process bytes that should have been skipped due to TTY errors. The TTY layer does not guarantee that cp[i] holds a meaningful value when fp[i] is set, so passing those positions to sixpack_decode() results in KMSAN reporting an uninit-value read. Fix this by processing bytes one at a time, advancing cp on each iteration, and only passing valid (non-error) bytes to sixpack_decode(). This matches the pattern used by slip_receive_buf() and mkiss_receive_buf() for the same purpose. Reported-by: syzbot+ecdb8c9878a81eb21e54@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=ecdb8c9878a81eb21e54 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Mashiro Chen <mashiro.chen@mailbox.org> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260407173101.107352-1-mashiro.chen@mailbox.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-10bpf: poison dead stack slotsAlexei Starovoitov
As a sanity check poison stack slots that stack liveness determined to be dead, so that any read from such slots will cause program rejection. If stack liveness logic is incorrect the poison can cause valid program to be rejected, but it also will prevent unsafe program to be accepted. Allow global subprogs "read" poisoned stack slots. The static stack liveness determined that subprog doesn't read certain stack slots, but sizeof(arg_type) based global subprog validation isn't accurate enough to know which slots will actually be read by the callee, so it needs to check full sizeof(arg_type) at the caller. Signed-off-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/r/20260410-patch-set-v4-14-5d4eecb343db@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-04-10selftests/bpf: add new tests for static stack liveness analysisAlexei Starovoitov
Add a bunch of new tests to verify the static stack liveness analysis. Signed-off-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/r/20260410-patch-set-v4-13-5d4eecb343db@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-04-10selftests/bpf: adjust verifier_log buffersAlexei Starovoitov
The new liveness analysis in liveness.c adds verbose output at BPF_LOG_LEVEL2, making the verifier log for good_prog exceed the 1024-byte reference buffer. When the reference is truncated in fixed mode, the rolling mode captures the actual tail of the full log, which doesn't match the truncated reference. The fix is to increase the buffer sizes in the test. Signed-off-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/r/20260410-patch-set-v4-12-5d4eecb343db@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-04-10selftests/bpf: update existing tests due to liveness changesAlexei Starovoitov
The verifier cleans all dead registers and stack slots in the current state. Adjust expected output in tests or insert dummy stack/register reads. Also update verifier_live_stack tests to adhere to new logging scheme. Signed-off-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/r/20260410-patch-set-v4-11-5d4eecb343db@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-04-10bpf: change logging scheme for live stack analysisEduard Zingerman
Instead of breadcrumbs like: (d2,cs15) frame 0 insn 18 +live -16 (d2,cs15) frame 0 insn 17 +live -16 Print final accumulated stack use/def data per-func_instance per-instruction. printed func_instance's are ordered by callsite and depth. For example: stack use/def subprog#0 shared_instance_must_write_overwrite (d0,cs0): 0: (b7) r1 = 1 1: (7b) *(u64 *)(r10 -8) = r1 ; def: fp0-8 2: (7b) *(u64 *)(r10 -16) = r1 ; def: fp0-16 3: (bf) r1 = r10 4: (07) r1 += -8 5: (bf) r2 = r10 6: (07) r2 += -16 7: (85) call pc+7 ; use: fp0-8 fp0-16 8: (bf) r1 = r10 9: (07) r1 += -16 10: (bf) r2 = r10 11: (07) r2 += -8 12: (85) call pc+2 ; use: fp0-8 fp0-16 13: (b7) r0 = 0 14: (95) exit stack use/def subprog#1 forwarding_rw (d1,cs7): 15: (85) call pc+1 ; use: fp0-8 fp0-16 16: (95) exit stack use/def subprog#1 forwarding_rw (d1,cs12): 15: (85) call pc+1 ; use: fp0-8 fp0-16 16: (95) exit stack use/def subprog#2 write_first_read_second (d2,cs15): 17: (7a) *(u64 *)(r1 +0) = 42 18: (79) r0 = *(u64 *)(r2 +0) ; use: fp0-8 fp0-16 19: (95) exit For groups of three or more consecutive stack slots, abbreviate as follows: 25: (85) call bpf_loop#181 ; use: fp2-8..-512 fp1-8..-512 fp0-8..-512 Signed-off-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/r/20260410-patch-set-v4-10-5d4eecb343db@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-04-10bpf: simplify liveness to use (callsite, depth) keyed func_instancesEduard Zingerman
Rework func_instance identification and remove the dynamic liveness API, completing the transition to fully static stack liveness analysis. Replace callchain-based func_instance keys with (callsite, depth) pairs. The full callchain (all ancestor callsites) is no longer part of the hash key; only the immediate callsite and the call depth matter. This does not lose precision in practice and simplifies the data structure significantly: struct callchain is removed entirely, func_instance stores just callsite, depth. Drop must_write_acc propagation. Previously, must_write marks were accumulated across successors and propagated to the caller via propagate_to_outer_instance(). Instead, callee entry liveness (live_before at subprog start) is pulled directly back to the caller's callsite in analyze_subprog() after each callee returns. Since (callsite, depth) instances are shared across different call chains that invoke the same subprog at the same depth, must_write marks from one call may be stale for another. To handle this, analyze_subprog() records into a fresh_instance() when the instance was already visited (must_write_initialized), then merge_instances() combines the results: may_read is unioned, must_write is intersected. This ensures only slots written on ALL paths through all call sites are marked as guaranteed writes. This replaces commit_stack_write_marks() logic. Skip recursive descent into callees that receive no FP-derived arguments (has_fp_args() check). This is needed because global subprogram calls can push depth beyond MAX_CALL_FRAMES (max depth is 64 for global calls but only 8 frames are accommodated for FP passing). It also handles the case where a callback subprog cannot be determined by argument tracking: such callbacks will be processed by analyze_subprog() at depth 0 independently. Update lookup_instance() (used by is_live_before queries) to search for the func_instance with maximal depth at the corresponding callsite, walking depth downward from frameno to 0. This accounts for the fact that instance depth no longer corresponds 1:1 to bpf_verifier_state->curframe, since skipped non-FP calls create gaps. Remove the dynamic public liveness API from verifier.c: - bpf_mark_stack_{read,write}(), bpf_reset/commit_stack_write_marks() - bpf_update_live_stack(), bpf_reset_live_stack_callchain() - All call sites in check_stack_{read,write}_fixed_off(), check_stack_range_initialized(), mark_stack_slot_obj_read(), mark/unmark_stack_slots_{dynptr,iter,irq_flag}() - The per-instruction write mark accumulation in do_check() - The bpf_update_live_stack() call in prepare_func_exit() mark_stack_read() and mark_stack_write() become static functions in liveness.c, called only from the static analysis pass. The func_instance->updated and must_write_dropped flags are removed. Remove spis_single_slot(), spis_one_bit() helpers from bpf_verifier.h as they are no longer used. Signed-off-by: Eduard Zingerman <eddyz87@gmail.com> Tested-by: Paul Chaignon <paul.chaignon@gmail.com> Link: https://lore.kernel.org/r/20260410-patch-set-v4-9-5d4eecb343db@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-04-10bpf: record arg tracking results in bpf_liveness masksEduard Zingerman
After arg tracking reaches a fixed point, perform a single linear scan over the converged at_in[] state and translate each memory access into liveness read/write masks on the func_instance: - Load/store instructions: FP-derived pointer's frame and offset(s) are converted to half-slot masks targeting per_frame_masks->{may_read,must_write} - Helper/kfunc calls: record_call_access() queries bpf_helper_stack_access_bytes() / bpf_kfunc_stack_access_bytes() for each FP-derived argument to determine access size and direction. Unknown access size (S64_MIN) conservatively marks all slots from fp_off to fp+0 as read. - Imprecise pointers (frame == ARG_IMPRECISE): conservatively mark all slots in every frame covered by the pointer's frame bitmask as fully read. - Static subprog calls with unresolved arguments: conservatively mark all frames as fully read. Instead of a call to clean_live_states(), start cleaning the current state continuously as registers and stack become dead since the static analysis provides complete liveness information. This makes clean_live_states() and bpf_verifier_state->cleaned unnecessary. Signed-off-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/r/20260410-patch-set-v4-8-5d4eecb343db@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-04-10bpf: introduce forward arg-tracking dataflow analysisEduard Zingerman
The analysis is a basis for static liveness tracking mechanism introduced by the next two commits. A forward fixed-point analysis that tracks which frame's FP each register value is derived from, and at what byte offset. This is needed because a callee can receive a pointer to its caller's stack frame (e.g. r1 = fp-16 at the call site), then do *(u64 *)(r1 + 0) inside the callee — a cross-frame stack access that the callee's local liveness must attribute to the caller's stack. Each register holds an arg_track value from a three-level lattice: - Precise {frame=N, off=[o1,o2,...]} — known frame index and up to 4 concrete byte offsets - Offset-imprecise {frame=N, off_cnt=0} — known frame, unknown offset - Fully-imprecise {frame=ARG_IMPRECISE, mask=bitmask} — unknown frame, mask says which frames might be involved At CFG merge points the lattice moves toward imprecision (same frame+offset stays precise, same frame different offsets merges offset sets or becomes offset-imprecise, different frames become fully-imprecise with OR'd bitmask). The analysis also tracks spills/fills to the callee's own stack (at_stack_in/out), so FP derived values spilled and reloaded. This pass is run recursively per call site: when subprog A calls B with specific FP-derived arguments, B is re-analyzed with those entry args. The recursion follows analyze_subprog -> compute_subprog_args -> (for each call insn) -> analyze_subprog. Subprogs that receive no FP-derived args are skipped during recursion and analyzed independently at depth 0. Signed-off-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/r/20260410-patch-set-v4-7-5d4eecb343db@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-04-10bpf: prepare liveness internal API for static analysis passEduard Zingerman
Move the `updated` check and reset from bpf_update_live_stack() into update_instance() itself, so callers outside the main loop can reuse it. Similarly, move write_insn_idx assignment out of reset_stack_write_marks() into its public caller, and thread insn_idx as a parameter to commit_stack_write_marks() instead of reading it from liveness->write_insn_idx. Drop the unused `env` parameter from alloc_frame_masks() and mark_stack_read(). Signed-off-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/r/20260410-patch-set-v4-6-5d4eecb343db@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-04-10bpf: 4-byte precise clean_verifier_stateEduard Zingerman
Migrate clean_verifier_state() and its liveness queries from 8-byte SPI granularity to 4-byte half-slot granularity. In __clean_func_state(), each SPI is cleaned in two independent halves: - half_spi 2*i (lo): slot_type[0..3] - half_spi 2*i+1 (hi): slot_type[4..7] Slot types STACK_DYNPTR, STACK_ITER and STACK_IRQ_FLAG are never cleaned, as their slot type markers are required by destroy_if_dynptr_stack_slot(), is_iter_reg_valid_uninit() and is_irq_flag_reg_valid_uninit() for correctness. When only the hi half is dead, spilled_ptr metadata is destroyed and the lo half's STACK_SPILL bytes are downgraded to STACK_MISC or STACK_ZERO. When only the lo half is dead, spilled_ptr is preserved because the hi half may still need it for state comparison. Signed-off-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/r/20260410-patch-set-v4-5-5d4eecb343db@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-04-10bpf: make liveness.c track stack with 4-byte granularityEduard Zingerman
Convert liveness bitmask type from u64 to spis_t, doubling the number of trackable stack slots from 64 to 128 to support 4-byte granularity. Each 8-byte SPI now maps to two consecutive 4-byte sub-slots in the bitmask: spi*2 half and spi*2+1 half. In verifier.c, check_stack_write_fixed_off() now reports 4-byte aligned writes of 4-byte writes as half-slot marks and 8-byte aligned 8-byte writes as two slots. Similar logic applied in check_stack_read_fixed_off(). Queries (is_live_before) are not yet migrated to half-slot granularity. Signed-off-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/r/20260410-patch-set-v4-4-5d4eecb343db@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-04-10bpf: Add spis_*() helpers for 4-byte stack slot bitmasksAlexei Starovoitov
Add helper functions for manipulating u64[2] bitmasks that represent 4-byte stack slot liveness. The 512-byte BPF stack is divided into 128 4-byte slots, requiring 128 bits (two u64s) to track. These will be used by the static stack liveness analysis in the next commit. Signed-off-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/r/20260410-patch-set-v4-3-5d4eecb343db@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-04-10bpf: save subprogram name in bpf_subprog_infoEduard Zingerman
Subprogram name can be computed from function info and BTF, but it is convenient to have the name readily available for logging purposes. Update comment saying that bpf_subprog_info->start has to be the first field, this is no longer true, relevant sites access .start field by it's name. Signed-off-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/r/20260410-patch-set-v4-2-5d4eecb343db@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-04-10bpf: share several utility functions as internal APIEduard Zingerman
Namely: - bpf_subprog_is_global - bpf_vlog_alignment Acked-by: Mykyta Yatsenko <yatsenko@meta.com> Signed-off-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/r/20260410-patch-set-v4-1-5d4eecb343db@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-04-10Merge tag 'spacemit-dt-for-7.1-1' of https://github.com/spacemit-com/linux ↵Linus Walleij
into soc/dt RISC-V SpacemiT DT changes for 7.1 For K3 SoC - Add I2C support - Add PMIC regulator tree - Add ethernet support - Add pinctrl/GPIO/Clock - Enable full UART support For K1 SoC On Milk-V Jupiter - Enable PCIe/USB on - Enable QSPI/SPI NOR - Enable EEPROM, LEDs Others - Fix PMIC supply properties - Fix PCIe missing power regulator * tag 'spacemit-dt-for-7.1-1' of https://github.com/spacemit-com/linux: dts: riscv: spacemit: k3: add P1 PMIC regulator tree dts: riscv: spacemit: k3: Add i2c nodes riscv: dts: spacemit: enable PCIe ports on Milk-V Jupiter riscv: dts: spacemit: enable USB 3 ports on Milk-V Jupiter riscv: dts: spacemit: enable QSPI and add SPI NOR on Milk-V Jupiter riscv: dts: spacemit: add i2c aliases on Milk-V Jupiter riscv: dts: spacemit: add 24c04 eeprom on Milk-V Jupiter riscv: dts: spacemit: add LEDs for Milk-V Jupiter board riscv: dts: spacemit: Add ethernet device for K3 riscv: dts: spacemit: drop incorrect pinctrl for combo PHY riscv: dts: spacemit: reorder phy nodes for K1 riscv: dts: spacemit: k3: add full resource to UART riscv: dts: spacemit: k3: add GPIO support riscv: dts: spacemit: k3: add pinctrl support riscv: dts: spacemit: k3: add clock tree dt-bindings: serial: 8250: spacemit: fix clock property for K3 SoC riscv: dts: spacemit: Add 'linux,pci-domain' to PCIe nodes for K1 riscv: dts: spacemit: adapt regulator node name to preferred form riscv: dts: spacemit: Update PMIC supply properties for BPI-F3 and Jupiter riscv: dts: spacemit: pcie: fix missing power regulator Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-04-11Merge tag 'drm-intel-fixes-2026-04-09' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/i915/kernel into drm-fixes - Drop check for changed VM in EXECBUF - Fix refcount underflow race in intel_engine_park_heartbeat - Do not use pipe_src as borders for SU area in PSR Signed-off-by: Dave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patch.msgid.link/add6fPHRC7Bc8Uri@jlahtine-mobl
2026-04-10i2c: usbio: Add ACPI device-id for NVL platformsArun T
Add device IDs of Nova Lake into i2c-usbio support list Signed-off-by: Arun T <arun.t@intel.com> Reviewed-by: Vadillo Miguel <miguel.vadillo@intel.com> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20260410080408.562311-1-arun.t@intel.com
2026-04-10clockevents: Prevent timer interrupt starvationThomas Gleixner
Calvin reported an odd NMI watchdog lockup which claims that the CPU locked up in user space. He provided a reproducer, which sets up a timerfd based timer and then rearms it in a loop with an absolute expiry time of 1ns. As the expiry time is in the past, the timer ends up as the first expiring timer in the per CPU hrtimer base and the clockevent device is programmed with the minimum delta value. If the machine is fast enough, this ends up in a endless loop of programming the delta value to the minimum value defined by the clock event device, before the timer interrupt can fire, which starves the interrupt and consequently triggers the lockup detector because the hrtimer callback of the lockup mechanism is never invoked. As a first step to prevent this, avoid reprogramming the clock event device when: - a forced minimum delta event is pending - the new expiry delta is less then or equal to the minimum delta Thanks to Calvin for providing the reproducer and to Borislav for testing and providing data from his Zen5 machine. The problem is not limited to Zen5, but depending on the underlying clock event device (e.g. TSC deadline timer on Intel) and the CPU speed not necessarily observable. This change serves only as the last resort and further changes will be made to prevent this scenario earlier in the call chain as far as possible. [ tglx: Updated to restore the old behaviour vs. !force and delta <= 0 and fixed up the tick-broadcast handlers as pointed out by Borislav ] Fixes: d316c57ff6bf ("[PATCH] clockevents: add core functionality") Reported-by: Calvin Owens <calvin@wbinvd.org> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Tested-by: Calvin Owens <calvin@wbinvd.org> Tested-by: Borislav Petkov <bp@alien8.de> Link: https://lore.kernel.org/lkml/acMe-QZUel-bBYUh@mozart.vkv.me/ Link: https://patch.msgid.link/20260407083247.562657657@kernel.org
2026-04-10i2c: qcom-geni: Avoid extra TX DMA TRE for single read message in GPI modeAniket Randive
In GPI mode, the I2C GENI driver programs an extra TX DMA transfer descriptor (TRE) on the TX channel when handling a single read message. This results in an unintended write phase being issued on the I2C bus, even though a read transaction does not require any TX data. For a single-byte read, the correct hardware sequence consists of the CONFIG and GO commands followed by a single RX DMA TRE. Programming an additional TX DMA TRE is redundant, causes unnecessary DMA buffer mapping on the TX channel, and may lead to incorrect bus behavior. Update the transfer logic to avoid programming a TX DMA TRE for single read messages in GPI mode. Co-developed-by: Maramaina Naresh <naresh.maramaina@oss.qualcomm.com> Signed-off-by: Maramaina Naresh <naresh.maramaina@oss.qualcomm.com> Signed-off-by: Aniket Randive <aniket.randive@oss.qualcomm.com> Reviewed-by: Mukesh Kumar Savaliya <mukesh.savaliya@oss.qualcomm.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20260410101949.2315058-1-aniket.randive@oss.qualcomm.com