summaryrefslogtreecommitdiff
path: root/include
AgeCommit message (Collapse)Author
2026-07-02Merge tag 'device-id-rework' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux Pull mod_devicetable.h header split from Uwe Kleine-König: "Split <linux/mod_devicetable.h> in per subsystem headers <linux/mod_devicetable.h> is included transitively in nearly every driver in an x86_64 allmodconfig build of v7.1: $ find drivers -name \*.o -not -name \*.mod.o | wc -l 21330 $ find drivers -name \*.o.cmd -not -name \*.mod.o.cmd | xargs grep -l mod_devicetable.h | wc -l 17038 The result of this mixture of different and unrelated subsystem details is that even when touching an obscure device id struct most of the kernel needs to be recompiled. Given that each driver typically only needs one or two of these structures, splitting into per subsystem headers and only including what is really needed reduces the amount of needed recompilation. This split is implemented in the first commit and then after some preparatory work in the following commits, the last two replace includes of <linux/mod_devicetable.h> by the actually needed more specific headers. There are still a few instances left, but the ones with high impact (that is in headers that are used a lot) and the easy ones (.c files) are handled. These remaining includes will be addressed during the next merge window" * tag 'device-id-rework' of git://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux: Replace <linux/mod_devicetable.h> by more specific <linux/device-id/*.h> (c files) Replace <linux/mod_devicetable.h> by more specific <linux/device-id/*.h> (headers) parisc: #include <linux/compiler.h> for unlikely() in <asm/ptrace.h> media: em28xx: Add include for struct usb_device_id LoongArch: KVM: Add include defining struct cpu_feature ALSA: hda/core: Add include defining struct hda_device_id usb: dwc2: Add include defining struct pci_device_id platform/x86: int3472: Add include defining struct dmi_system_id platform/x86: x86-android-tablets: Add include defining struct dmi_system_id i2c: Let i2c-core.h include <linux/i2c.h> of: Explicitly include <linux/types.h> and <linux/err.h> platform/x86: msi-ec: Ensure dmi_system_id is defined usb: serial: Include <linux/usb.h> in <linux/usb/serial.h> driver core: platform: Include header for struct platform_device_id driver: core: Include headers for acpi_device_id and of_device_id for struct device_driver media: ti: vpe: #include <linux/platform_device.h> explicitly mod_devicetable.h: Split into per subsystem headers
2026-07-03net: ipv4: report multicast group user countYuyang Huang
RTM_GETMULTICAST has been part of the rtnetlink ABI for a long time and already reports IPv4 multicast group membership through IFA_MULTICAST and IFA_CACHEINFO. It does not report how many consumers hold each membership, so userspace still has to parse /proc/net/igmp to get the Users column. Add IFA_MC_USERS as a u32 attribute carrying ip_mc_list::users in RTM_GETMULTICAST replies and entry-lifecycle notifications. This gives iproute2 enough information to migrate the IPv4 part of "ip maddr show" from procfs parsing to rtnetlink. Signed-off-by: Yuyang Huang <sigefriedhyy@gmail.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260630110207.37841-2-sigefriedhyy@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-03Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netPaolo Abeni
Cross-merge networking fixes after downstream PR (net-7.2-rc2). No conflicts. Adjacent changes: MAINTAINERS: 56114690ff3c ("MAINTAINERS: Update Marvell octeontx2 driver maintainers") eb56577ae9a5 ("ehea: remove the ehea driver") net/core/netpoll.c: 45f1458a8501 ("netpoll: fix a use-after-free on shutdown path") 84c0ff1efb62 ("netpoll: do not warn when the best-effort pool refill fails") Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-03Replace <linux/mod_devicetable.h> by more specific <linux/device-id/*.h> ↵Uwe Kleine-König (The Capable Hub)
(headers) <linux/mod_devicetable.h> is included in a many files: $ git grep '<linux/mod_devicetable.h>' ef0c9f75a195 | wc -l 1598 ; some of them are widely used headers. To stop mixing up different and unrelated driver( type)s let the subsystem headers only use the subset of the recently split <linux/mod_devicetable.h> that are relevant for them. The fallout (I hope) is addressed in the previous commits that handle sources relying on e.g. <linux/i2c.h> pulling in the full legacy header and thus providing pci_device_id. Acked-by: Danilo Krummrich <dakr@kernel.org> Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://patch.msgid.link/199fe46b624ba07fb9bd3e0cd6ff13757932cb5f.1782808461.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
2026-07-03ALSA: hda/core: Add include defining struct hda_device_idUwe Kleine-König (The Capable Hub)
Traditionally all *_device_id were defined in a single header <linux/mod_devicetable.h>. This was split now with the objective that only the relevant bits are included. So including <linux/pci.h> won't be enough to get a definition of (the unrelated to pci) struct hda_device_id. Add an explicit include for the header defining struct hda_device_id to keep working when <linux/pci.h> stops providing this defintion. Acked-by: Danilo Krummrich <dakr@kernel.org> Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Reviewed-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/376883bc5889d5cca01efb6f8d4e07a20158f2b8.1782808461.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
2026-07-03platform/x86: int3472: Add include defining struct dmi_system_idUwe Kleine-König (The Capable Hub)
Currently <linux/mod_devicetable.h> is included transitively in int3472.h via <linux/clk-provider.h> -> <linux/of.h> -> <linux/mod_devicetable.h> However these includes will be tightend such that only the bits relevant for of will be provided by <linux/of.h>. To ensure that dmi_system_id stays around, include the respective header explicitly. Acked-by: Danilo Krummrich <dakr@kernel.org> Acked-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Link: https://patch.msgid.link/0ba52730f67dc995d9d896b81fa6a7320bf8cb4b.1782808461.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
2026-07-03of: Explicitly include <linux/types.h> and <linux/err.h>Uwe Kleine-König (The Capable Hub)
<linux/of_platform.h> uses resource_size_t and relies on the transitive include <linux/mod_devicetable.h> -> <linux/types.h>. It also uses error constants and thus relying on the include chain <linux/mod_devicetable.h> -> <linux/uuid.h> -> <linux/string.h> -> <linux/err.h>. With the plan to split <linux/mod_devicetable.h> per subsystem and then only letting of_platform.h include the of-specific bits (which don't require these two headers), add the needed includes explicitly to keep the header self-contained. Acked-by: Danilo Krummrich <dakr@kernel.org> Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://patch.msgid.link/a730991bc8813cf70c2445064ea425291538f709.1782808461.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
2026-07-03usb: serial: Include <linux/usb.h> in <linux/usb/serial.h>Uwe Kleine-König (The Capable Hub)
All consumers of the latter also include the former, but without that struct usb_driver and struct usb_device_id (and maybe more) are not defined. Add an include for <linux/usb.h> to make the header self-contained. Acked-by: Danilo Krummrich <dakr@kernel.org> Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://patch.msgid.link/82219ab65d16ee5bfe5a35d11bc938baac3fd3bc.1782808461.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
2026-07-03driver core: platform: Include header for struct platform_device_idUwe Kleine-König (The Capable Hub)
Platform drivers can define an array containing the supported device variants to be assigned to the struct platform_driver's .id_table. While a forward declaration of struct platform_device_id is technically enough to make the driver self-contained, it's reasonable to provide the (very lightweight) data type definition for that array in <linux/platform_device.h> to not add that burden to all platform drivers with an id-table. Note that currently <linux/device.h> transitively includes <linux/mod_devicetable.h> that provides struct platform_device_id. But that include is planned to be replaced by a tighter set of includes that only define the structures relevant for the stuff in <linux/device.h>. Acked-by: Danilo Krummrich <dakr@kernel.org> Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://patch.msgid.link/4ca29592c9d1c6d528a65e05b80af7355f3c79c5.1782808461.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
2026-07-03driver: core: Include headers for acpi_device_id and of_device_id for struct ↵Uwe Kleine-König (The Capable Hub)
device_driver struct device_driver contains pointers of type struct of_device_id* and struct acpi_device_id* but doesn't ensure these are defined. To make the header self-contained add the (very lightweight) includes that contain the respective definitions. Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Danilo Krummrich <dakr@kernel.org> Acked-by: Rafael J. Wysocki (Intel) <rafael@kernel.org> Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://patch.msgid.link/199ba71b4ac73f4b4d9f5d2be635c96eec73c70e.1782808461.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
2026-07-03mod_devicetable.h: Split into per subsystem headersUwe Kleine-König (The Capable Hub)
<linux/mod_devicetable.h> is included transitively in nearly every driver in an x86_64 allmodconfig build of v7.1: $ find drivers -name \*.o -not -name \*.mod.o | wc -l 21330 $ find drivers -name \*.o.cmd -not -name \*.mod.o.cmd | xargs grep -l mod_devicetable.h | wc -l 17038 The result is that even when touching an obscure device id struct most of the kernel needs to be recompiled. Given that each driver typically only needs one or two of these structures, splitting into per subsystem headers and only including what is really needed reduces the amount of needed recompilation. Implement the first step and define each device id struct in a separate header (together with its associated #defines). <linux/mod_devicetable.h> is modified to include all the new headers to continue to provide the same symbols. Several headers currently include <linux/mod_devicetable.h>, those that are most lukrative to include only their subsystem headers only are: $ git -C source grep -l mod_devicetable.h include/linux | while read h; do echo -n "$h:"; find drivers -name \*.o.cmd -not -name \*.mod.o.cmd | xargs grep -l $h | wc -l; done | sort -t: -k2 -n -r | head include/linux/of.h:10897 include/linux/pci.h:7920 include/linux/acpi.h:7097 include/linux/i2c.h:5402 include/linux/spi/spi.h:1897 include/linux/dmi.h:1643 include/linux/usb.h:1222 include/linux/input.h:1205 include/linux/mdio.h:835 include/linux/phy.h:733 struct cpu_feature isn't really a device_id struct. That is kept in <linux/mod_devicetable.h> for now. Acked-by: Danilo Krummrich <dakr@kernel.org> Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> # zorro Link: https://patch.msgid.link/41400e323be8640702b906d04327e833c5bdaf4a.1782808461.git.u.kleine-koenig@baylibre.com [Drop "MOD" from the header guards] Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
2026-07-02Merge tag 'bpf-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpfLinus Torvalds
Pull BPF fixes from Daniel Borkmann: - Initialize task local storage before fork bails out to free the task (Jann Horn) - Fix insn_aux_data leak on verifier error path (KaFai Wan) - Reject BPF inode storage map creation when BPF LSM is uninitialized (Matt Bobrowski) - Mask pseudo pointer values in verifier logs when pointer leaks are not allowed (Nuoqi Gui) - Harden BPF JIT against spraying via IBPB flush (Pawan Gupta) - Reject a skb-modifying SK_SKB stream parser since the latter is only meant to measure the next message (Sechang Lim) - Fix bpf_refcount_acquire to reject refcounted allocation arguments with a non-zero fixed offset (Yiyang Chen) * tag 'bpf-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf: bpf: Prefer dirty packs for eBPF allocations bpf: Prefer packs that won't trigger an IBPB flush on allocation bpf: Skip redundant IBPB in pack allocator bpf: Restrict JIT predictor flush to cBPF x86/bugs: Enable IBPB flush on BPF JIT allocation bpf: Support for hardening against JIT spraying bpf: Reject BPF_MAP_TYPE_INODE_STORAGE creation if BPF LSM is uninitialized bpf,fork: wipe ->bpf_storage before bailouts that access it bpf: Fix insn_aux_data leak on verifier err_free_env path selftests/bpf: Cover pseudo-BTF ksym log masking bpf: Mask pseudo pointer values in verifier logs selftests/bpf: Cover refcount acquire node offsets bpf: Reject offset refcount acquire arguments selftests/bpf: test rejection of a packet-modifying SK_SKB stream parser bpf, sockmap: reject a packet-modifying SK_SKB stream parser selftests/bpf: don't modify the skb in the strparser parser prog
2026-07-02Merge tag 'vfio-v7.2-rc2' of https://github.com/awilliam/linux-vfioLinus Torvalds
Pull VFIO fixes from Alex Williamson: "Mostly straightforward fixes here, inconsistent runtime PM handling due to global device policies, bitfield races, unwind path gaps, teardown ordering, and a misplaced library flag. - Fix racy bitfield updates in vfio-pci-core and the mlx5 vfio-pci variant driver with a binary split between setup/release and runtime modified flags. These were noted across several Sashiko reviews as pre-existing issues (Alex Williamson) - Fix runtime PM inconsistency where the vfio-pci driver module_init could modify the idle PM policy of existing devices through globals managed in vfio-pci-core, leading to unbalanced runtime PM operations (Alex Williamson) - Restore mutability of writable vfio-pci module options by further pulling policy globals out of vfio-pci-core, to instead be latched per device at device init. Provide visibility of the per device latched values through debugfs (Alex Williamson) - Fix missing VGA arbiter uninit callback in unwind path (Alex Williamson) - Reorder device debugfs removal before device_del() to avoid gap where debugfs is available with stale devres pointers (Alex Williamson) - Move UUID library linking flag from vfio selftest Makefile into libvfio.mk to avoid exposing such dependencies when linking with KVM selftests (Sean Christopherson)" * tag 'vfio-v7.2-rc2' of https://github.com/awilliam/linux-vfio: vfio: selftests: Add luuid to libvfio.mk's list of libraries, not to the Makefile vfio/pci: Expose latched module parameter policy in debugfs vfio: Remove device debugfs before releasing devres vfio/pci: Latch all module parameters per device vfio/mlx5: Fix racy bitfields and tighten struct layout vfio/pci: Fix racy bitfields and tighten struct layout vfio/pci: Release the VGA arbiter client on register_device() failure vfio/pci: Latch disable_idle_d3 per device
2026-07-02Merge tag 'net-7.2-rc2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Paolo Abeni: "Including fixes from netfilter and batman-adv. Current release - new code bugs: - netfilter: cthelper: cap to maximum number of expectation per master Previous releases - regressions: - netpoll: fix a use-after-free on shutdown path - tcp: restore RCU grace period in tcp_ao_destroy_sock - ipv6: fix NULL deref in fib6_walk_continiue() on multi-batch dump - batman-adv: dat: ensure accessible eth_hdr proto field - eth: - virtio_net: disable cb when NAPI is busy-polled - lan743x: Initialize eth_syslock spinlock before use Previous releases - always broken: - netfilter: - nft_set_pipapo: don't leak bad clone into future transaction - sched: - sch_teql: Introduce slaves_lock to avoid race condition and UAF - replace direct dequeue call with peek and qdisc_dequeue_peeked - sctp: add INIT verification after cookie unpacking - tipc: fix out-of-bounds read in broadcast Gap ACK blocks - seg6: validate SRH length before reading fixed fields - eth: - mlx5e: fix use-after-free of metadata_dst on RX SC delete - enetc: check the number of BDs needed for xdp_frame - fbnic: don't cache shinfo across skb realloc" * tag 'net-7.2-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (58 commits) net/mlx5: HWS, fix matcher leak on resize target setup failure net/sched: hhf: clear heavy-hitter state on reset net/sched: dualpi2: clear stale classification on filter miss net/sched: act_bpf: use rcu_dereference_bh() to read the filter selftests: drv-net: tso: don't touch dangerous feature bits cxgb4: Fix decode strings dump for T6 adapters virtio_net: disable cb when NAPI is busy-polled sctp: fix addr_wq_timer race in sctp_free_addr_wq() selftests: net: bump default cmd() timeout to 20 seconds bridge: stp: Fix a potential use-after-free when deleting a bridge net/sched: sch_teql: Introduce slaves_lock to avoid race condition and UAF net: gianfar: dispose irq mappings on probe failure and device removal net: lan743x: Initialize eth_syslock spinlock before use net: libwx: fix VMDQ mask for 1-queue mode net: airoha: fix max receive size configuration fsl/fman: Free init resources on KeyGen failure in fman_init() netfilter: nftables: restrict checkum update offset netfilter: nftables: restrict linklayer and network header writes netfilter: nfnetlink_queue: restrict writes to network header netfilter: nft_fib: reject fib expression on the netdev egress hook ...
2026-07-02dmaengine: qcom: bam_dma: Fix command element mask field for BAM v1.6.0+Md Sadre Alam
BAM version 1.6.0 and later changed the behavior of the mask field in command elements for read operations. In older BAM versions, or prior implementation assumptions, the mask field was effectively ignored for read commands. However, starting from BAM v1.6.0, the mask field for read commands is repurposed to carry the upper 4 bits of the destination address, enabling support for 36-bit addressing. For write commands, the mask field continues to function as a traditional write mask. The current driver sets mask = 0xffffffff for all command elements. While this works for write operations, it breaks read operations on BAM v1.6.0+ hardware. In such cases, the hardware interprets the upper address bits as 0xf, resulting in an invalid destination address (0xf_xxxxxxxx instead of 0x0_xxxxxxxx). This leads to failures such as NAND enumeration issues observed on platforms like IPQ5424. Fix this by assigning the mask field based on command type: - For read commands: set mask = 0 (upper address bits = 0) - For write commands: retain mask = 0xffffffff Also update the bam_cmd_element structure documentation to reflect the dual purpose of the mask field across BAM versions. This ensures correct behavior on BAM v1.6.0+ while maintaining backward compatibility with older hardware. Fixes: dfebb055f73a2 ("dmaengine: qcom: bam_dma: wrapper functions for command descriptor") Tested-by: Lakshmi Sowjanya D <lakshmi.d@oss.qualcomm.com> Signed-off-by: Md Sadre Alam <md.alam@oss.qualcomm.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Cc: stable@vger.kernel.org Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com> Link: https://patch.msgid.link/20260615060908.1263171-1-varadarajan.narayanan@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-07-02dt-bindings: iio: adc: mediatek,mt6359-auxadc: add mt6323 PMIC AUXADCRoman Vivchar
The MediaTek mt6323 PMIC includes an AUXADC used for battery voltage, temperature, and other internal measurements. The IP block is not register-compatible with mt6359. Add the devicetree binding documentation and the associated header file defining the ADC channel constants. Also change the description to 'MT6350 series and similar' because the binding already includes more than mt635x series PMICs. Finally, add the MAINTAINERS entry for the header with ADC constants. Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Roman Vivchar <rva333@protonmail.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2026-07-02bootconfig: add xbc_prepend_embedded_cmdline() helperBreno Leitao
Add a helper that prepends the build-time-rendered embedded bootconfig "kernel" subtree (embedded_kernel_cmdline[] from embedded-cmdline.S) to a cmdline buffer with a separating space. Architectures call this from setup_arch() before parse_early_param() so early_param() handlers (mem=, earlycon=, loglevel=, ...) see values supplied via the embedded bootconfig. The in-place prepend (shift the existing string right, then drop the embedded string in front) is factored into a small str_prepend() helper. On overflow the helper logs an error and leaves the cmdline untouched rather than panicking. Booting without the embedded values is better than refusing to boot, and the error tells the user why their embedded keys are missing. The helper records whether it actually prepended, exposed via xbc_embedded_cmdline_applied(). setup_boot_config() uses this to decide whether the runtime "kernel" render would duplicate keys already folded into boot_command_line. Also add bootconfig_cmdline_requested(), a small parse_args() wrapper that reports whether "bootconfig" was passed on the command line and, via an optional out-parameter, where the "--" init arguments begin. setup_arch() and setup_boot_config() share it so the early and late paths agree on the opt-in. It sits under CONFIG_BOOT_CONFIG rather than CONFIG_CMDLINE_FROM_BOOTCONFIG because the runtime parser needs it on every bootconfig build. When CONFIG_CMDLINE_FROM_BOOTCONFIG=n, the public declaration in <linux/bootconfig.h> resolves to a no-op stub so callers compile unchanged. Link: https://lore.kernel.org/all/20260626-bootconfig_using_tools-v7-5-24ab72139c29@debian.org/ Signed-off-by: Breno Leitao <leitao@debian.org> Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
2026-07-02kprobes: Replace __ASSEMBLY__ with __ASSEMBLER__ in header fileThomas Huth
While the GCC and Clang compilers already define __ASSEMBLER__ automatically when compiling assembly code, __ASSEMBLY__ is a macro that only gets defined by the Makefiles in the kernel. This can be very confusing when switching between userspace and kernelspace coding, or when dealing with uapi headers that rather should use __ASSEMBLER__ instead. So let's standardize now on the __ASSEMBLER__ macro that is provided by the compilers. Link: https://lore.kernel.org/all/20260619161434.88270-1-thuth@redhat.com/ Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
2026-07-02udp: convert udp_lib_getsockopt to sockopt_tBreno Leitao
In preparation for converting the proto-layer getsockopt callbacks to the sockopt_t interface, switch udp_lib_getsockopt() to take a sockopt_t. The thin udp_getsockopt()/udpv6_getsockopt() wrappers keep their __user signature for now: they build a user-backed sockopt_t with sockopt_init_user(), call the helper, and write the returned length back to optlen. The helper uses copy_to_iter() instead of copy_to_user(). No functional change. Signed-off-by: Breno Leitao <leitao@debian.org> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Acked-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260630-getsockopt_phase2-v2-2-193335f3d4d1@debian.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-02net: add sockopt_init_user() for getsockopt conversionBreno Leitao
Add a helper that initializes a user-backed sockopt_t from the (optval, optlen) __user pair passed to a getsockopt() callback. It is used by transitional __user getsockopt wrappers while the proto-layer getsockopt callbacks are converted to take a sockopt_t, and is removed once the conversion is complete. The goal is to help to convert leafs. Example: sock_common_getsockopt(... char __user *optval, int __user *optlen) → udp_getsockopt(sk, level, optname, optval__user, optlen__user) → udp_lib_getsockopt(sk, level, optname, &opt) /* needs a sockopt_t */ Signed-off-by: Breno Leitao <leitao@debian.org> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Acked-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260630-getsockopt_phase2-v2-1-193335f3d4d1@debian.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-02netfilter: conntrack: remove obsolete module parametersFlorian Westphal
helper autoassign was removed years ago, all the port numbers are no longer functional. Signed-off-by: Florian Westphal <fw@strlen.de>
2026-07-02netfilter: conntrack: get rid of tuple in helper definitionsFlorian Westphal
Leftover from the days when the kernel did automatic assignment of helpers based on a pre-registered / well-known-port. This helper autoassign was removed from the kernel, so all we really need are the l3 and l4 protocol numbers. In the broadcast helper, the only remaining consumer of the port number is removed. AFAICS its not needed: The expectation is populated from the control connection reply tuple, so the src port is the original directions destination (snmp/161 for example). LLM complained about silent l3num (u16) -> nfproto (u8) truncation, so add a netlink policy validation to reject large NFPROTO values upfront. Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Florian Westphal <fw@strlen.de>
2026-07-02netfilter: replace u_int8_t and u_int16t with u8 and u16Carlos Grillet
Use preferred kernel integer type u8 instead of the POSIX u_int8_t variant. No functional change. Signed-off-by: Carlos Grillet <carlos@carlosgrillet.me> Signed-off-by: Florian Westphal <fw@strlen.de>
2026-07-02netfilter: nfnetlink_hook: Dump nat type chainsPhil Sutter
These chains are indirectly attached to the hook since they are not called for packets belonging to an established connection. Introduce NF_HOOK_OP_NAT to identify the container and dump attached entries instead of the container itself. Dump these entries with the dispatcher's priority value since their own priority merely defines ordering within the dispatcher's list. Signed-off-by: Phil Sutter <phil@nwl.cc> Signed-off-by: Florian Westphal <fw@strlen.de>
2026-07-02mm/mm_init: handle alloc_percpu failure in free_area_init_core_hotplugGregory Price
We miss a failed allocation check for pgdat->per_cpu_nodestats, which results in a NULL deref when we offset into the per-cpu area. Propagate -ENOMEM up the stack and leave per_cpu_nodestats pointing at boot_nodestats so a later online can retry the allocation. hotadd_init_pgdat() returns NULL on failure, which __try_online_node() already maps to -ENOMEM. On failure nothing needs to be unwound: - the node is never marked online - per_cpu_nodestats is left pointing at boot_nodestats - __add_memory_resource() cleans up pending memblock resources - later online attempts retry the per_cpu_nodestats allocation Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://sashiko.dev/#/patchset/20260627202243.758289-1-gourry%40gourry.net Fixes: 75ef71840539 ("mm, vmstat: add infrastructure for per-node vmstats") Signed-off-by: Gregory Price <gourry@gourry.net> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Link: https://patch.msgid.link/20260701221613.2818148-1-gourry@gourry.net Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
2026-07-02dma_buf: change unsigned int and int types into size_tShahyan Soltani
The num_fences, count, i, and j variables in dma_fence_dedup_array() and __dma_fence_unwrap_merge() have inconsistent integer types, mixing both unsigned int and int. Use type size_t consistently for these instead, and update the return type of dma_fence_dedup_array() accordingly. Signed-off-by: Shahyan Soltani <shahyan.soltani@amd.com> Suggested-by: Philipp Stanner <phasta@mailbox.org> Link: https://lore.kernel.org/r/20260630160401.67544-1-shahyan.soltani@amd.com Reviewed-by: Philipp Stanner <phasta@kernel.org> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com>
2026-07-02xfrm: cache the offload ifindex for netlink dumpsCen Zhang
copy_to_user_state_extra() only holds a reference to the outer xfrm_state. That does not pin x->xso.dev. NETDEV_DOWN and NETDEV_UNREGISTER can race through xfrm_dev_state_flush(), xfrm_state_delete(), and xfrm_dev_state_free(), which clears xso->dev and drops the netdev reference before the GETSA dump reaches xso_to_xuo() and reads xso->dev->ifindex. The buggy scenario involves two paths, with each column showing the order within that path: XFRM_MSG_GETSA dump path: NETDEV teardown path: 1. xfrm_get_sa() gets xfrm_state 1. xfrm_dev_state_flush() finds x 2. copy_to_user_state_extra() sees 2. xfrm_state_delete() removes x x->xso.dev from the SAD 3. copy_user_offload() calls 3. xfrm_dev_state_free() clears xso_to_xuo() xso->dev 4. xso->dev->ifindex dereferences 4. netdev_put() drops the device a detached net_device reference Avoid following the live net_device from the dump paths. Cache the attached ifindex in xfrm_dev_offload when state or policy offload is bound to a device, and serialize that snapshot instead. This preserves the user-visible XFRMA_OFFLOAD_DEV value without depending on the embedded net_device lifetime. Validation reproduced this kernel report: Oops: general protection fault Call Trace: <TASK> copy_to_user_state_extra+0xb8d/0x1370 [xfrm_user] ? __pfx_copy_to_user_state_extra+0x10/0x10 [xfrm_user] ? __asan_memset+0x23/0x50 ? srso_alias_return_thunk+0x5/0xfbef5 ? __alloc_skb+0x342/0x960 ? srso_alias_return_thunk+0x5/0xfbef5 ? __asan_memset+0x23/0x50 ? srso_alias_return_thunk+0x5/0xfbef5 ? __nlmsg_put+0x147/0x1b0 dump_one_state+0x1c7/0x3e0 [xfrm_user] xfrm_state_netlink+0xcb/0x130 [xfrm_user] ? __pfx_xfrm_state_netlink+0x10/0x10 [xfrm_user] ? srso_alias_return_thunk+0x5/0xfbef5 ? xfrm_user_state_lookup.constprop.0+0x230/0x310 [xfrm_user] xfrm_get_sa+0x102/0x250 [xfrm_user] ? __pfx_xfrm_get_sa+0x10/0x10 [xfrm_user] xfrm_user_rcv_msg+0x504/0xaa0 [xfrm_user] ? __pfx_xfrm_user_rcv_msg+0x10/0x10 [xfrm_user] ? srso_alias_return_thunk+0x5/0xfbef5 ? stack_trace_save+0x8e/0xc0 ? __pfx_stack_trace_save+0x10/0x10 netlink_rcv_skb+0x11f/0x350 ? __pfx_xfrm_user_rcv_msg+0x10/0x10 [xfrm_user] ? __pfx_netlink_rcv_skb+0x10/0x10 ? __pfx_mutex_lock+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 xfrm_netlink_rcv+0x65/0x80 [xfrm_user] netlink_unicast+0x600/0x870 ? __pfx_netlink_unicast+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __pfx_stack_trace_save+0x10/0x10 netlink_sendmsg+0x75d/0xc10 ? __pfx_netlink_sendmsg+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ____sys_sendmsg+0x77a/0x900 ? srso_alias_return_thunk+0x5/0xfbef5 ? __pfx_____sys_sendmsg+0x10/0x10 ? __pfx_copy_msghdr_from_user+0x10/0x10 ? release_sock+0x1a/0x1d0 ? srso_alias_return_thunk+0x5/0xfbef5 ? netlink_insert+0x143/0xec0 ___sys_sendmsg+0xff/0x180 ? __pfx____sys_sendmsg+0x10/0x10 ? _raw_spin_lock_irqsave+0x85/0xe0 ? do_getsockname+0xf9/0x170 ? srso_alias_return_thunk+0x5/0xfbef5 ? fdget+0x53/0x3b0 __sys_sendmsg+0x111/0x1a0 ? __pfx___sys_sendmsg+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __sys_getsockname+0x8c/0x100 do_syscall_64+0x102/0x5a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: 07b87f9eea0c ("xfrm: Fix unregister netdevice hang on hardware offload.") Assisted-by: Codex:gpt-5.5 Signed-off-by: Cen Zhang <zzzccc427@gmail.com> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
2026-07-01mm: do file ownership checks with the proper mount idmapPedro Falcato
Ever since idmapped mounts were introduced, inode ownership checks (for side-channel protection) in mincore() and madvise(MADV_PAGEOUT) were done against the nop_mnt_idmap, which completely ignores the file's mount's idmap. This results in odd edgecases like: 1) mount/bind-mount with an idmap userA:userB:1 2) userB runs an owner_or_capable() check on file that is owned by userA on-disk/in-memory, but owned by userB after idmap translation 3) owner_or_capable() mysteriously fails as the correct idmap wasn't supplied In the case of mincore/madvise MADV_PAGEOUT, this is usually benign, because file_permission(file, MAY_WRITE) will probably succeed, as it uses the proper idmap internally, but it does not need to be the case on e.g a 0444 file where even the owner itself doesn't have permissions to write to it. Since this is clearly not trivial to get right, introduce a file_owner_or_capable() that can carry the correct semantics, and switch the various users in mm to it. The issue was found by manual code inspection & an off-list discussion with Jan Kara. Link: https://lore.kernel.org/20260625153853.913949-1-pfalcato@suse.de Fixes: 9caccd41541a ("fs: introduce MOUNT_ATTR_IDMAP") Signed-off-by: Pedro Falcato <pfalcato@suse.de> Reviewed-by: Jan Kara <jack@suse.cz> Reviewed-by: Christian Brauner (Amutable) <brauner@kernel.org> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Jann Horn <jannh@google.com> Cc: Liam R. Howlett <liam@infradead.org> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Vlastimil Babka <vbabka@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-01mm/damon: add a kernel-doc comment for damon_ctx->rnd_stateSJ Park
Fix below kernel document build warning: WARNING: ../include/linux/damon.h:909 struct member 'rnd_state' not described in 'damon_ctx' Link: https://lore.kernel.org/20260628220808.98931-3-sj@kernel.org Fixes: 9012c4e647df ("mm/damon: replace damon_rand() with a per-ctx lockless PRNG") Signed-off-by: SJ Park <sj@kernel.org> Reported-by: Randy Dunlap <rdunlap@infradead.org> Closes: https://lore.kernel.org/4df95955-b255-4e5a-90c4-35db02f3111f@infradead.org Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-01mm/damon: add a kernel-doc comment for damon_ctx->probesSJ Park
The two fields of damon_ctx struct dont have their kernel-doc comments. That causes kernel document builds to warn. Fix those. This patch (of 2): Fix below document build warning: WARNING: ../include/linux/damon.h:909 struct member 'probes' not described in 'damon_ctx' Link: https://lore.kernel.org/20260628220808.98931-1-sj@kernel.org Link: https://lore.kernel.org/20260628220808.98931-2-sj@kernel.org Fixes: 18c777859f28 ("mm/damon/core: embed damon_probe objects in damon_ctx") Signed-off-by: SJ Park <sj@kernel.org> Reported-by: Randy Dunlap <rdunlap@infradead.org> Closes: https://lore.kernel.org/4df95955-b255-4e5a-90c4-35db02f3111f@infradead.org Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-01mm: page_ext: add count limit to page_ext_iter_next to prevent invalid PFN ↵Ketan
access The page_ext iteration API does not validate if the PFN still belongs to a valid section while advancing the iterator. When dynamically adding memory in the hotplug path, it can lead to a NULL pointer dereference during page_ext_lookup at the boundary of the last valid section when iterator count equals __pgcount. The for_each_page_ext() macro calls page_ext_iter_next() as its loop increment. for_each_page_ext() does a "__page_ext = page_ext_iter_next(&__iter)" at the end. This causes page_ext_iter_next() to increment iter->index past __pgcount and call page_ext_lookup(start_pfn + __pgcount). During memory hotplug (online), the PFN at start_pfn + __pgcount may belong to a section that has not yet been initialized, causing page_ext_lookup() to trigger a NULL pointer dereference. [ 14.555124][ T846] Call trace: [ 14.555125][ T846] lookup_page_ext+0x6c/0x108 (P) [ 14.555127][ T846] page_ext_lookup+0x30/0x3c [ 14.555129][ T846] __reset_page_owner+0x11c/0x260 [ 14.571201][ T846] __free_pages_ok+0x5e8/0x8e0 [ 14.571204][ T846] __free_pages_core+0x78/0xf0 [ 14.571206][ T846] generic_online_page+0x14/0x24 [ 14.597782][ T846] online_pages+0x178/0x30c [ 14.597784][ T846] memory_block_change_state+0x284/0x32c [ 14.597787][ T846] memory_subsys_online+0x4c/0x64 [ 14.597789][ T846] device_online+0x88/0xb0 [ 14.597791][ T846] online_memory_block+0x30/0x40 [ 14.597793][ T846] walk_memory_blocks+0xac/0xe8 [ 14.597794][ T846] add_memory_resource+0x280/0x298 [ 14.656161][ T846] add_memory+0x60/0x98 Move the iteration boundary enforcement inside the iterator functions, so callers cannot inadvertently access beyond the requested range. Link: https://lore.kernel.org/20260623-page_ext-v3-1-a89799a5367c@oss.qualcomm.com Fixes: 9039b9096ea2 ("mm: page_ext: add an iteration API for page extensions") Signed-off-by: Ketan Kishore <ketan.kishore@oss.qualcomm.com> Suggested-by: David Hildenbrand <david@redhat.com> Suggested-by: Matthew Wilcox <willy@infradead.org> Acked-by: Zi Yan <ziy@nvidia.com> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Cc: Brendan Jackman <jackmanb@google.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Liam R. Howlett <liam@infradead.org> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Luiz Capitulino <luizcap@redhat.com> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Vlastimil Babka <vbabka@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-01mm/damon/ops-common: handle extreme intervals in damon_hot_score()SeongJae Park
Fix three issues in damon_hot_score() that comes from wrong handling of extreme (zero or too high) monitoring intervals user setup. When the user sets sampling interval zero, damon_max_nr_accesses(), which is called from damon_hot_score(), causes a divide-by-zero. Needless to say, it is a problem. When the user sets the aggregation interval zero, the function returns zero. It is wrong, since the real maximum nr_acceses in the setup should be one. Worse yet, it can cause another divide-by-zero from its caller, damon_hot_score(), since it uses damon_max_nr_accesses() return value as a denominator. When the user sets the aggregation interval very high, damon_hot_score() could return a value out of [0, DAMOS_MAX_SCORE] range. Since the return value is used as an index to the regions_score_histogram array, which is DAMOS_MAX_SCORE+1 size, it causes out of bounds array access. The issues can be relatively easily reproduced like below. The sysfs write permission is required, though. # ./damo start --damos_action lru_prio --damos_quota_space 100M \ --damos_quota_interval 1s # cd /sys/kernel/mm/damon/admin/kdamonds/0 # echo 0 > contexts/0/monitoring_attrs/intervals/sample_us # echo 0 > contexts/0/monitoring_attrs/intervals/aggr_us # echo commit > state # dmesg [...] [ 131.329762] Oops: divide error: 0000 [#1] SMP NOPTI [...] [ 131.336089] RIP: 0010:damon_hot_score+0x27/0xd0 [...] Fix the divide-by-zero intervals problems by explicitly handling the zero intervals in damon_max_nr_accesses(). Fix the out-of-bound array access by applying [0, DAMOS_MAX_SCORE] bounds before returning from damon_hot_score(). The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260623135834.67189-1-sj@kernel.org Link: https://lore.kernel.org/20260619202459.145010-1-sj@kernel.org [1] Fixes: 198f0f4c58b9 ("mm/damon/vaddr,paddr: support pageout prioritization") Signed-off-by: SeongJae Park <sj@kernel.org> Cc: <stable@vger.kernel.org> # 5.16.x Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-01leds: trigger: netdev: Extend speeds up to 100GMike Marciniszyn (Meta)
Add 25G, 40G, 50G, and 100G as available speeds to the netdev LED trigger. Signed-off-by: Mike Marciniszyn (Meta) <mike.marciniszyn@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260520200337.204431-2-mike.marciniszyn@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-07-01bpf: Add tracing_multi link info supportJiri Olsa
Adding BPF_OBJ_GET_INFO_BY_FD support for tracing_multi links. We expose following tracing_multi link data: - attach_type of the program - number of ids - array of BTF ids - array of its related kernel addresses - array of cookies The change follows the kprobe_multi and uprobe_multi link-info convention of optional output arrays with an in/out count, On top of standard tracing link data we also expose addresses, because they are useful info for user (especially when the attachment was done via pattern). This data is hidden when kallsyms does not allow exposing kernel pointer values. Assisted-by: Codex:GPT-5 Signed-off-by: Jiri Olsa <jolsa@kernel.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Leon Hwang <leon.hwang@linux.dev> Acked-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20260629212208.895962-2-jolsa@kernel.org
2026-07-01bpf: Copy per-CPU map value padding in copy_map_value_long()Leon Hwang
In kernel, per-CPU map elements are stored with round_up(map->value_size, 8) bytes. On UAPI lookup paths, it copies the rounded size for each CPU into a temporary buffer. However, copy_map_value_long() passes 'map->value_size' to bpf_obj_memcpy(). When the map has special fields, bpf_obj_memcpy() copies around those fields with memcpy(), and does not copy the tail padding between 'map->value_size' and round_up(map->value_size, 8). The temporary UAPI lookup buffers are allocated without __GFP_ZERO. As a result, when the per-CPU map's value size is not equal to round_up(map->value_size, 8), UAPI LOOKUP_ELEM and its variants can return stale heap contents from that padding to user space. The same issue applies to bpf_iter for per-CPU maps. Pass round_up(map->value_size, 8) to bpf_obj_memcpy() from copy_map_value_long(), so per-CPU maps both with and without special fields copy the entire per-CPU slot. Remove the now redundant round_up() from bpf_obj_memcpy()'s long_memcpy path. Fixes: 448325199f57 ("bpf: Add copy_map_value_long to copy to remote percpu memory") Signed-off-by: Leon Hwang <leon.hwang@linux.dev> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20260624155115.85196-2-leon.hwang@linux.dev
2026-07-01RDMA/nldev: Add resource summary max values for usage displayTao Cui
Add RDMA_NLDEV_ATTR_RES_SUMMARY_ENTRY_MAX netlink attribute to expose device resource limits (max_qp, max_cq, max_mr, max_pd, max_srq) in the resource summary alongside the existing current count. This allows userspace tools like iproute2's rdma to display resource usage in curr/max format. Expected output from "rdma resource show": Before: 0: mlx5_0: qp 123 cq 45 mr 200 pd 10 After: 0: mlx5_0: qp 123/131072 cq 45/65536 mr 200/1000000 pd 10/32768 In JSON output, both "curr" and "max" fields will be provided so that scripts can compute percentages if needed. The new attribute is optional and backward compatible - old userspace tools will simply ignore it. Signed-off-by: Tao Cui <cuitao@kylinos.cn> Link: https://patch.msgid.link/20260615003646.168704-1-cui.tao@linux.dev Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-07-01net: fib_rules: Only hold RTNL for the first IPv4 RTM_NEWRULE.Kuniyuki Iwashima
Now, RTM_DELRULE no longer needs RTNL, and the only RTNL dependant in RTM_NEWRULE is fib_unmerge(), which is called for the first IPv4 rule. Let's add fib_rules_ops.need_rtnl() and hold RTNL only for the first IPv4 rule. Tested: The script below creates 1K rules in parallel in 4K netns, and it got 20x/30x faster for IPv4/IPv6. #!/bin/bash N=4096 F=rules.txt for i in $(seq $N); do ip netns add ns-$i; done printf 'rule add from all table %d\n' {1..1024} > $F for v in 4 6; do echo "=== IPv${v} ===" time { for i in $(seq $N); do nsenter \ --net=/var/run/netns/ns-$i ip -$v -batch $F & done; wait; } done for i in $(seq $N); do ip netns del ns-$i; done rm -f $F Without this series: # ./test.sh === IPv4 === real 0m22.752s user 0m7.834s sys 92m46.721s === IPv6 === real 0m35.181s user 0m8.635s sys 142m30.479s With this series: # ./test.sh === IPv4 === real 0m0.918s user 0m5.675s sys 2m7.024s === IPv6 === real 0m1.214s user 0m7.917s sys 4m19.489s Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260629181226.1929658-10-kuniyu@google.com Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-01net: fib_rules: Add fib_rules_ops.lock.Kuniyuki Iwashima
We will no longer hold RTNL for RTM_NEWRULE and RMT_DELRULE except for the first IPv4 RTM_NEWRULE. Let's add per-fib_rules_ops mutex inside RTNL. Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260629181226.1929658-6-kuniyu@google.com Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-01ipv4: fib: Drop RTNL annotation for net->ipv4.fib_table_hash[].Kuniyuki Iwashima
fib_newrule() will drop RTNL except for the first IPv4 rule. net->ipv4.fib_table_hash[] will be read with no protection, but this is fine because fib_table is not destroyed until netns dismantle except for the merged main/local table. fib_unmerge() will continue to be called under RTNL, so other readers (fib_flush() and fib_info_notify_update()) just have to care about the concurrent hlist_add(). IPv6 and IPMR/IP6MR also take this strategy and use RCU helpers to avoid data race against concurrent hlist_add(). Let's not use lockdep_rtnl_is_held() and rcu_dereference_rtnl() for net->ipv4.fib_table_hash[]. Note that commit a7e53531234d ("fib_trie: Make fib_table rcu safe") started to use the _safe version in fib_flush(), but it is not needed thanks to RTNL. Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260629181226.1929658-5-kuniyu@google.com Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-01ipv4: fib: Protect fib_new_table() with spinlock.Kuniyuki Iwashima
fib_newrule() will drop RTNL except for the first IPv4 rule. Then, fib4_rule_configure() could call fib_empty_table() and create a new IPv4 fib_table without RTNL. Currently, net->ipv4.fib_table_hash[] is only protected by RTNL. As a prep, let's protect net->ipv4.fib_table_hash[] with a dedicated spinlock. Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260629181226.1929658-4-kuniyu@google.com Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-01net: fib_rules: Make fib_rules_ops.delete() return void.Kuniyuki Iwashima
Since commit d954a67a7dfa ("ipv4: fib_rule: Move fib4_rules_exit() to ->exit()."), both fib4_rule_delete() and fib6_rule_delete() always return 0. Let's change the return type to void. Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260629181226.1929658-2-kuniyu@google.com Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-01dma-buf: rename dma_fence_enable_sw_signalingChristian König
Dropping the _sw_ part from the names was proposed multiple times now and IIRC people generally agreed with the idea already. The function requests a fence to signal and triggers some sort of HW interaction on most backends. So this is not really software related at all and the callback is already just named enable_signaling as well. Just streamline that and use a consistent name everywhere. Assisted-by: Claude Sonet 4 Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Link: https://lore.kernel.org/r/20260624122917.2483-2-christian.koenig@amd.com
2026-07-01iomap: consolidate bio submissionChristoph Hellwig
Add a iomap_bio_submit_read_endio helper factored out of iomap_bio_submit_read to that all ->submit_read implementations for iomap_read_ops that use iomap_bio_read_folio_range can shared the logic. Right now that logic is mostly trivial, but already has a bug for XFS because the XFS version is too trivial: file system integrity validation needs a workqueue context and thus can't happen from the default iomap bi_end_io I/O handler. Unfortunately the iomap refactoring just before fs integrity landed moved code around here and the call go misplaced, meaning it never got called. The PI information still is verified by the block layer, but the offloading is less efficient (and the future userspace interface can't get at it). Fixes: 0b10a370529c ("iomap: support T10 protection information") Cc: stable@vger.kernel.org # v7.1 Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://patch.msgid.link/20260629121750.3392300-2-hch@lst.de Acked-by: Namjae Jeon <linkinjeon@kernel.org> Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Reviewed-by: Joanne Koong <joannelkoong@gmail.com> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-07-01netfs: Replace wb_lock with a bit lock for asynchronicityDavid Howells
The netfs_inode::wb_lock mutex is used to prevent multiple simultaneous writebacks from fighting each other (a writeback thread will write multiple discontiguous regions within the same request). The mutex, however, only serialises the issuing of subrequests; it doesn't serialise the collection of results, and, in particular, the updating of file size information and fscache populatedness data. Unfortunately, the mutex cannot be held around the entire process as it has to be unlocked in the same thread in which it is locked - and we don't want to hold up the allocator whilst we complete the writeback. Fix this by replacing the mutex with a bit flag and a list of lock waiters so that the lock can be dropped in the collector thread after collection is complete. Link: https://sashiko.dev/#/patchset/20260608145432.681865-1-dhowells%40redhat.com Signed-off-by: David Howells <dhowells@redhat.com> Link: https://patch.msgid.link/20260625140640.3116900-12-dhowells@redhat.com cc: Paulo Alcantara <pc@manguebit.org> cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-07-01netfs: Fix kdoc warningDavid Howells
Fix a kdoc warning due to a misnamed parameter in the description. Reported-by: Matthew Wilcox <willy@infradead.org> Signed-off-by: David Howells <dhowells@redhat.com> Link: https://patch.msgid.link/20260625140640.3116900-11-dhowells@redhat.com cc: Paulo Alcantara <pc@manguebit.org> cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-07-01dt-bindings: reset: altr: add COMBOPHY_RESET for Agilex5Tanmay Kathpalia
Add COMBOPHY_RESET definition at index 38 for the combo PHY reset control on Altera Agilex5 SoCs. This reset is used by peripherals such as the SD/eMMC controller that share the combo PHY. Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2026-07-01ACPICA: Define acpi_ut_safe_strncpy() as strscpy_pad() aliasRafael J. Wysocki
Commit 292db66afd20 ("ACPICA: Unbreak tools build after switching over to strscpy_pad()") added an #ifdef based on a __KERNEL__ check which is sort of nasty to the acpi_ut_safe_strncpy() definition to unbreak ACPICA tools builds broken by commit 97f7d3f9c9ac ("ACPICA: Replace strncpy() with strscpy_pad() in acpi_ut_safe_strncpy()"). However, that #ifdef effectively produces dead code when tools are built because they don't call acpi_ut_safe_strncpy(). Accordingly, drop the existing definition of acpi_ut_safe_strncpy() and define it as a strscpy_pad() alias. Fixes: 292db66afd20 ("ACPICA: Unbreak tools build after switching over to strscpy_pad()") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> [ rjw: Tweak the changelog ] Link: https://patch.msgid.link/12941764.O9o76ZdvQC@rafael.j.wysocki Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-07-01kexec: Replace __ASSEMBLY__ with __ASSEMBLER__ in header fileThomas Huth
While the GCC and Clang compilers already define __ASSEMBLER__ automatically when compiling assembly code, __ASSEMBLY__ is a macro that only gets defined by the Makefiles in the kernel. This can be very confusing when switching between userspace and kernelspace coding, or when dealing with uapi headers that rather should use __ASSEMBLER__ instead. So let's standardize now on the __ASSEMBLER__ macro that is provided by the compilers. Signed-off-by: Thomas Huth <thuth@redhat.com> Acked-by: Pratyush Yadav <pratyush@kernel.org> Link: https://patch.msgid.link/20260619160654.75980-1-thuth@redhat.com Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
2026-07-01bpf: Restrict JIT predictor flush to cBPFPawan Gupta
Currently predictor flush on memory reuse is done for all BPF JIT allocations, but only cBPF programs can be loaded by an unprivileged user. eBPF is privileged by default, and flushing predictors for all CPUs on every eBPF reuse penalizes the common case for no security benefit. eBPF allocations can be frequent on busy systems, only flush predictors for cBPF programs. Trampoline and dispatcher allocations also skip the flush as they are eBPF-only. Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2026-07-01bpf: Support for hardening against JIT sprayingPawan Gupta
The BPF JIT allocator packs many small programs into larger executable allocations and reuses space within those allocations as programs are loaded and freed. When fresh code is written into space that a previous program occupied, an indirect jump into the new program can reuse a branch prediction left behind by the old one. Flush the indirect branch predictors before reusing JIT memory so that indirect jumps into a newly written program don't reuse predictions from an old program that occupied the same space. Introduce bpf_arch_pred_flush_enabled static key and bpf_arch_pred_flush static call for flushing the branch predictors on JIT memory reuse. Architectures that need a flush, can update it to a predictor flush function. By default, its a NOP and does not emit any CALL. Allocations larger than a pack are not covered by this flush. That is safe because cBPF programs (the unprivileged attack surface) are bounded well below a pack size. Issue a warning if this assumption is ever violated while the flush is active. Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>