aboutsummaryrefslogtreecommitdiffstats
path: root/compat
diff options
context:
space:
mode:
Diffstat (limited to 'compat')
0 files changed, 0 insertions, 0 deletions
generated by cgit v1.2.3 (git 2.39.1) at 2026-01-04 14:36:04 +0000
: keep .modinfo section in vmlinux.unstripped"), there is an error with binutils 2.31.1 or earlier because these sections are not properly removed: s390-linux-objcopy: st6tO8Ev: symbol `.modinfo' required but not present s390-linux-objcopy:st6tO8Ev: no symbols Add the old pattern to resolve this issue (along with a comment to allow cleaning this when binutils 2.32 or newer is the minimum supported version). While the aforementioned kbuild change exposes this, the pattern was originally changed by commit 71d815bf5dfd ("kbuild: Strip runtime const RELA sections correctly"), where it would still be incorrect with binutils older than 2.32. Fixes: 71d815bf5dfd ("kbuild: Strip runtime const RELA sections correctly") Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=c12d9fa2afe7abcbe407a00e15719e1a1350c2a7 [1] Reported-by: Linux Kernel Functional Testing <lkft@linaro.org> Closes: https://lore.kernel.org/CA+G9fYvVktRhFtZXdNgVOL8j+ArsJDpvMLgCitaQvQmCx=hwOQ@mail.gmail.com/ Acked-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Alexey Gladkov <legion@kernel.org> Acked-by: Nicolas Schier <nsc@kernel.org> Link: https://patch.msgid.link/20251008-kbuild-fix-modinfo-regressions-v1-2-9fc776c5887c@kernel.org Signed-off-by: Nathan Chancellor <nathan@kernel.org> 2025-10-10kbuild: Restore pattern to avoid stripping .rela.dyn from vmlinuxNathan Chancellor1-1/+1 Commit 0ce5139fd96e ("kbuild: always create intermediate vmlinux.unstripped") removed the pattern to avoid stripping .rela.dyn sections added by commit e9d86b8e17e7 ("scripts: Do not strip .rela.dyn section"). Restore it so that .rela.dyn sections remain in the final vmlinux. Fixes: 0ce5139fd96e ("kbuild: always create intermediate vmlinux.unstripped") Acked-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Alexey Gladkov <legion@kernel.org> Acked-by: Nicolas Schier <nsc@kernel.org> Link: https://patch.msgid.link/20251008-kbuild-fix-modinfo-regressions-v1-1-9fc776c5887c@kernel.org Signed-off-by: Nathan Chancellor <nathan@kernel.org> 2025-10-07gen_init_cpio: Ignore fsync() returning EINVAL on pipesDmitry Safonov1-1/+4 The reproducer: echo | ./usr/gen_init_cpio /dev/stdin > /dev/null fsync() on a pipe fd returns -EINVAL, which makes gen_init_cpio fail. Ignore -EINVAL from fsync(). Fixes: ae18b94099b0 ("gen_init_cpio: support -o <output_file> parameter") Cc: David Disseldorp <ddiss@suse.de> Cc: Nicolas Schier <nsc@kernel.org> Signed-off-by: Dmitry Safonov <dima@arista.com> Reviewed-by: David Disseldorp <ddiss@suse.de> Link: https://patch.msgid.link/20251007-gen_init_cpio-pipe-v2-1-b098ab94b58a@arista.com Signed-off-by: Nathan Chancellor <nathan@kernel.org> 2025-10-07scripts/Makefile.extrawarn: Respect CONFIG_WERROR / W=e for hostprogsNathan Chancellor1-3/+5 Commit 27758d8c2583 ("kbuild: enable -Werror for hostprogs") unconditionally enabled -Werror for the compiler, assembler, and linker when building the host programs, as the build footprint of the host programs is small (thus risk of build failures from warnings are low) and that stage of the build may not have Kconfig values (thus CONFIG_WERROR could not be used as a precondition). While turning warnings into errors unconditionally happens in a few places within the kernel, it can be disruptive to people who may be building with newer compilers, such as while doing a bisect. While it is possible to avoid this behavior by passing HOSTCFLAGS=-w or HOSTCFLAGS=-Wno-error, it may not be the most intuitive for regular users not intimately familiar with Kbuild. Avoid being disruptive to the entire build by depending on the explicit opt-in of CONFIG_WERROR or W=e to enable -Werror and the like while building the host programs. While this means there is a small portion of the build that does not have -Werror enabled (namely scripts/kconfig/* and scripts/basic/fixdep), it is better than not having it altogether. Fixes: 27758d8c2583 ("kbuild: enable -Werror for hostprogs") Acked-by: Miguel Ojeda <ojeda@kernel.org> Reported-by: Askar Safin <safinaskar@gmail.com> Closes: https://lore.kernel.org/20251005011100.1035272-1-safinaskar@gmail.com/ Reviewed-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Tested-by: Miguel Ojeda <ojeda@kernel.org> # Rust Link: https://patch.msgid.link/20251006-kbuild-hostprogs-werror-fix-v1-1-23cf1ffced5c@kernel.org Signed-off-by: Nathan Chancellor <nathan@kernel.org> 2025-10-06kbuild: uapi: Strip comments before size type checkGeert Uytterhoeven1-0/+2 On m68k, check_sizetypes in headers_check reports: ./usr/include/asm/bootinfo-amiga.h:17: found __[us]{8,16,32,64} type without #include <linux/types.h> This header file does not use any of the Linux-specific integer types, but merely refers to them from comments, so this is a false positive. As of commit c3a9d74ee413bdb3 ("kbuild: uapi: upgrade check_sizetypes() warning to error"), this check was promoted to an error, breaking m68k all{mod,yes}config builds. Fix this by stripping simple comments before looking for Linux-specific integer types. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Link: https://patch.msgid.link/949f096337e28d50510e970ae3ba3ec9c1342ec0.1759753998.git.geert@linux-m68k.org [nathan: Adjust comment and remove unnecessary escaping from slashes in regex] Signed-off-by: Nathan Chancellor <nathan@kernel.org> 2025-09-28modpost: Initialize builtin_modname to stop SIGSEGVsHugh Dickins1-0/+1 Segmentation fault ./scripts/mod/modpost -o vmlinux.symvers vmlinux.o stops the kernel build. It comes when write_vmlinux_export_c_file() tries to buf_printf alias->builtin_modname. malloc'ed memory is not necessarily zeroed. NULL new->builtin_modname before adding to aliases. Fixes: 5ab23c7923a1 ("modpost: Create modalias for builtin modules") Signed-off-by: Hugh Dickins <hughd@google.com> Reviewed-by: Nicolas Schier <nsc@kernel.org> Link: https://patch.msgid.link/4590a243-0a7e-b7e6-e2d3-cd1b41a12237@google.com Signed-off-by: Nathan Chancellor <nathan@kernel.org> 2025-09-25Documentation: kbuild: note CONFIG_DEBUG_EFI in reproducible buildsMasahiro Yamada1-0/+3 CONFIG_EFI_DEBUG embeds absolute file paths into object files, which makes the resulting vmlinux specific to the build environment. Add a note about this in reproducible-builds.rst Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Nicolas Schier <nsc@kernel.org> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> Link: https://patch.msgid.link/20250924-kbuild-doc-config-debug-efi-in-reproducible-builds-v2-1-d2d6b9dcdb7d@kernel.org Signed-off-by: Nathan Chancellor <nathan@kernel.org> 2025-09-24kbuild: vmlinux.unstripped should always depend on .vmlinux.export.oAlexey Gladkov2-11/+3 Since .vmlinux.export.c is used to add generated by modpost modaliases for builtin modules the .vmlinux.export.o is no longer optional and should always be created. The generation of this file is not dependent on CONFIG_MODULES. Signed-off-by: Alexey Gladkov <legion@kernel.org> Reviewed-by: Nicolas Schier <nsc@kernel.org> Link: https://patch.msgid.link/0e63a9c7741fe8217e4fd7c60afcf057ffa2ef5a.1758182101.git.legion@kernel.org Signed-off-by: Nathan Chancellor <nathan@kernel.org> 2025-09-24modpost: Create modalias for builtin modulesAlexey Gladkov6-6/+41 For some modules, modalias is generated using the modpost utility and the section is added to the module file. When a module is added inside vmlinux, modpost does not generate modalias for such modules and the information is lost. As a result kmod (which uses modules.builtin.modinfo in userspace) cannot determine that modalias is handled by a builtin kernel module. $ cat /sys/devices/pci0000:00/0000:00:14.0/modalias pci:v00008086d0000A36Dsv00001043sd00008694bc0Csc03i30 $ modinfo xhci_pci name: xhci_pci filename: (builtin) license: GPL file: drivers/usb/host/xhci-pci description: xHCI PCI Host Controller Driver Missing modalias "pci:v*d*sv*sd*bc0Csc03i30*" which will be generated by modpost if the module is built separately. To fix this it is necessary to generate the same modalias for vmlinux as for the individual modules. Fortunately '.vmlinux.export.o' is already generated from which '.modinfo' can be extracted in the same way as for vmlinux.o. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Alexey Gladkov <legion@kernel.org> Tested-by: Stephen Rothwell <sfr@canb.auug.org.au> Reviewed-by: Nicolas Schier <nsc@kernel.org> Link: https://patch.msgid.link/28d4da3b0e3fc8474142746bcf469e03752c3208.1758182101.git.legion@kernel.org Signed-off-by: Nathan Chancellor <nathan@kernel.org> 2025-09-24modpost: Add modname to mod_device_table aliasAlexey Gladkov3-8/+29 At this point, if a symbol is compiled as part of the kernel, information about which module the symbol belongs to is lost. To save this it is possible to add the module name to the alias name. It's not very pretty, but it's possible for now. Cc: Miguel Ojeda <ojeda@kernel.org> Cc: Andreas Hindborg <a.hindborg@kernel.org> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Alex Gaynor <alex.gaynor@gmail.com> Cc: rust-for-linux@vger.kernel.org Signed-off-by: Alexey Gladkov <legion@kernel.org> Acked-by: Danilo Krummrich <dakr@kernel.org> Acked-by: Nicolas Schier <nsc@kernel.org> Link: https://patch.msgid.link/1a0d0bd87a4981d465b9ed21e14f4e78eaa03ded.1758182101.git.legion@kernel.org Signed-off-by: Nathan Chancellor <nathan@kernel.org> 2025-09-24scsi: Always define blogic_pci_tbl structureAlexey Gladkov1-3/+1 The blogic_pci_tbl structure is used by the MODULE_DEVICE_TABLE macro. There is no longer a need to protect it with the MODULE condition, since this no longer causes the compiler to warn about an unused variable. To avoid warnings when -Wunused-const-variable option is used, mark it as __maybe_unused for such configuration. Cc: Khalid Aziz <khalid@gonehiking.org> Cc: Martin K. Petersen <martin.petersen@oracle.com> Cc: linux-scsi@vger.kernel.org Suggested-by: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Alexey Gladkov <legion@kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Acked-by: Martin K. Petersen <martin.petersen@oracle.com> Link: https://patch.msgid.link/fd8e30de07de79a4923ae967eaee5ba2f2fcef00.1758182101.git.legion@kernel.org Signed-off-by: Nathan Chancellor <nathan@kernel.org> 2025-09-24kbuild: extract modules.builtin.modinfo from vmlinux.unstrippedMasahiro Yamada2-25/+27 Currently, we assume all the data for modules.builtin.modinfo are available in vmlinux.o. This makes it impossible for modpost, which is invoked after vmlinux.o, to add additional module info. This commit moves the modules.builtin.modinfo rule after modpost. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Alexey Gladkov <legion@kernel.org> Reviewed-by: Nicolas Schier <nsc@kernel.org> Link: https://patch.msgid.link/cdb3e5b9a739666b755cd0097dc34ab69c350e51.1758182101.git.legion@kernel.org Signed-off-by: Nathan Chancellor <nathan@kernel.org> 2025-09-24kbuild: keep .modinfo section in vmlinux.unstrippedMasahiro Yamada3-3/+9 Keep the .modinfo section during linking, but strip it from the final vmlinux. Adjust scripts/mksysmap to exclude modinfo symbols from kallsyms. This change will allow the next commit to extract the .modinfo section from the vmlinux.unstripped intermediate. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Alexey Gladkov <legion@kernel.org> Reviewed-by: Nicolas Schier <nsc@kernel.org> Link: https://patch.msgid.link/aaf67c07447215463300fccaa758904bac42f992.1758182101.git.legion@kernel.org Signed-off-by: Nathan Chancellor <nathan@kernel.org> 2025-09-24kbuild: always create intermediate vmlinux.unstrippedMasahiro Yamada1-23/+22 Generate the intermediate vmlinux.unstripped regardless of CONFIG_ARCH_VMLINUX_NEEDS_RELOCS. If CONFIG_ARCH_VMLINUX_NEEDS_RELOCS is unset, vmlinux.unstripped and vmlinux are identiacal. This simplifies the build rule, and allows to strip more sections by adding them to remove-section-y. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <nsc@kernel.org> Link: https://patch.msgid.link/a48ca543fa2305bd17324f41606dcaed9b19f2d4.1758182101.git.legion@kernel.org Signed-off-by: Nathan Chancellor <nathan@kernel.org> 2025-09-24s390: vmlinux.lds.S: Reorder sectionsAlexey Gladkov1-5/+5 In the upcoming changes, the ELF_DETAILS macro will be extended with the ".modinfo" section, which will cause an error: >> s390x-linux-ld: .tmp_vmlinux1: warning: allocated section `.modinfo' not in segment >> s390x-linux-ld: .tmp_vmlinux2: warning: allocated section `.modinfo' not in segment >> s390x-linux-ld: vmlinux.unstripped: warning: allocated section `.modinfo' not in segment This happens because the .vmlinux.info use :NONE to override the default segment and tell the linker to not put the section in any segment at all. To avoid this, we need to change the sections order that will be placed in the default segment. Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Cc: Alexander Gordeev <agordeev@linux.ibm.com> Cc: linux-s390@vger.kernel.org Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202506062053.zbkFBEnJ-lkp@intel.com/ Signed-off-by: Alexey Gladkov <legion@kernel.org> Acked-by: Heiko Carstens <hca@linux.ibm.com> Link: https://patch.msgid.link/20d40a7a3a053ba06a54155e777dcde7fdada1db.1758182101.git.legion@kernel.org Signed-off-by: Nathan Chancellor <nathan@kernel.org> 2025-09-14Linux 6.17-rc6v6.17-rc6Linus Torvalds1-1/+1 2025-09-13MAINTAINERS: Input: Drop melfas-mip4 sectionKrzysztof Kozlowski1-7/+0 Emails to the sole melfas-mip4 driver maintainer bounce: 550 <jeesw@melfas.com> No such user here (connected from melfas.com) so clearly this is not a supported driver anymore. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250910142526.105286-2-krzysztof.kozlowski@linaro.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> 2025-09-12USB: core: remove the move buf actionEdward Adam Davis1-2/+2 The buffer size of sysfs is fixed at PAGE_SIZE, and the page offset of the buf parameter of sysfs_emit_at() must be 0, there is no need to manually manage the buf pointer offset. Fixes: 711d41ab4a0e ("usb: core: Use sysfs_emit_at() when showing dynamic IDs") Reported-by: syzbot+b6445765657b5855e869@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=b6445765657b5855e869 Tested-by: syzbot+b6445765657b5855e869@syzkaller.appspotmail.com Signed-off-by: Edward Adam Davis <eadavis@qq.com> Link: https://lore.kernel.org/r/tencent_B32D6D8C9450EBFEEE5ACC2C7B0E6C402D0A@qq.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2025-09-11MAINTAINERS: Update the DMA Rust entryDanilo Krummrich1-2/+2 Update the DMA Rust maintainers entry in the following two aspects: (1) Change Abdiel's entry to 'Reviewer'. (2) Take patches through the driver-core tree. Abdiel won't do any more maintainer work on the DMA (or scatterlist) infrastructure, but he'd like to be kept in the loop, hence change is entry to 'R:'. Analogous to [1], the DMA (and scatterlist) helpers are closely coupled with the core device infrastructure and the device lifecycle, hence take patches through the driver-core tree by default. Cc: Abdiel Janulgue <abdiel.janulgue@gmail.com> Link: https://lore.kernel.org/r/20250725202840.2251768-1-ojeda@kernel.org [1] Acked-by: Abdiel Janulgue <abdiel.janulgue@gmail.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Danilo Krummrich <dakr@kernel.org> 2025-09-12erofs: fix long xattr name prefix placementGao Xiang3-6/+16 Currently, xattr name prefixes are forcibly placed into the packed inode if the fragments feature is enabled, and users have no option to put them in plain form directly on disk. This is inflexible. First, as mentioned above, users should be able to store unwrapped long xattr name prefixes unconditionally (COMPAT_PLAIN_XATTR_PFX). Second, since we now have the new metabox inode to store metadata, it should be used when available instead of the packed inode. Fixes: 414091322c63 ("erofs: implement metadata compression") Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com> 2025-09-11Revert "net: usb: asix: ax88772: drop phylink use in PM to avoid MDIO ↵Paolo Abeni1-0/+13 runtime PM wakeups" This reverts commit 5537a4679403 ("net: usb: asix: ax88772: drop phylink use in PM to avoid MDIO runtime PM wakeups"), it breaks operation of asix ethernet usb dongle after system suspend-resume cycle. Link: https://lore.kernel.org/all/b5ea8296-f981-445d-a09a-2f389d7f6fdd@samsung.com/ Fixes: 5537a4679403 ("net: usb: asix: ax88772: drop phylink use in PM to avoid MDIO runtime PM wakeups") Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Jakub Kicinski <kuba@kernel.org> Link: https://patch.msgid.link/2945b9dbadb8ee1fee058b19554a5cb14f1763c1.1757601118.git.pabeni@redhat.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> 2025-09-11hsr: hold rcu and dev lock for hsr_get_port_ndevHangbin Liu2-7/+20 hsr_get_port_ndev calls hsr_for_each_port, which need to hold rcu lock. On the other hand, before return the port device, we need to hold the device reference to avoid UaF in the caller function. Suggested-by: Paolo Abeni <pabeni@redhat.com> Fixes: 9c10dd8eed74 ("net: hsr: Create and export hsr_get_port_ndev()") Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250905091533.377443-4-liuhangbin@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> 2025-09-11hsr: use hsr_for_each_port_rtnl in hsr_port_get_hsrHangbin Liu2-1/+4 hsr_port_get_hsr() iterates over ports using hsr_for_each_port(), but many of its callers do not hold the required RCU lock. Switch to hsr_for_each_port_rtnl(), since most callers already hold the rtnl lock. After review, all callers are covered by either the rtnl lock or the RCU lock, except hsr_dev_xmit(). Fix this by adding an RCU read lock there. Fixes: c5a759117210 ("net/hsr: Use list_head (and rcu) instead of array for slave devices.") Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250905091533.377443-3-liuhangbin@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> 2025-09-11hsr: use rtnl lock when iterating over portsHangbin Liu3-10/+13 hsr_for_each_port is called in many places without holding the RCU read lock, this may trigger warnings on debug kernels. Most of the callers are actually hold rtnl lock. So add a new helper hsr_for_each_port_rtnl to allow callers in suitable contexts to iterate ports safely without explicit RCU locking. This patch only fixed the callers that is hold rtnl lock. Other caller issues will be fixed in later patches. Fixes: c5a759117210 ("net/hsr: Use list_head (and rcu) instead of array for slave devices.") Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250905091533.377443-2-liuhangbin@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> 2025-09-11wifi: nl80211: completely disable per-link stats for nowJohannes Berg1-1/+1 After commit 8cc71fc3b82b ("wifi: cfg80211: Fix "no buffer space available" error in nl80211_get_station() for MLO"), the per-link data is only included in station dumps, where the size limit is somewhat less of an issue. However, it's still an issue, depending on how many links a station has and how much per-link data there is. Thus, for now, disable per-link statistics entirely. A complete fix will need to take this into account, make it opt-in by userspace, and change the dump format to be able to split a single station's data across multiple netlink dump messages, which all together is too much development for a fix. Fixes: 82d7f841d9bd ("wifi: cfg80211: extend to embed link level statistics in NL message") Signed-off-by: Johannes Berg <johannes.berg@intel.com> 2025-09-10net: usb: asix: ax88772: drop phylink use in PM to avoid MDIO runtime PM wakeupsOleksij Rempel1-13/+0 Drop phylink_{suspend,resume}() from ax88772 PM callbacks. MDIO bus accesses have their own runtime-PM handling and will try to wake the device if it is suspended. Such wake attempts must not happen from PM callbacks while the device PM lock is held. Since phylink {sus|re}sume may trigger MDIO, it must not be called in PM context. No extra phylink PM handling is required for this driver: - .ndo_open/.ndo_stop control the phylink start/stop lifecycle. - ethtool/phylib entry points run in process context, not PM. - phylink MAC ops program the MAC on link changes after resume. Fixes: e0bffe3e6894 ("net: asix: ax88772: migrate to phylink") Reported-by: Hubert Wiśniewski <hubert.wisniewski.25632@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Tested-by: Hubert Wiśniewski <hubert.wisniewski.25632@gmail.com> Tested-by: Xu Yang <xu.yang_2@nxp.com> Link: https://patch.msgid.link/20250908112619.2900723-1-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org> 2025-09-10net: ethtool: fix wrong type used in struct kernel_ethtool_ts_infoRussell King (Oracle)1-2/+2 In C, enumerated types do not have a defined size, apart from being compatible with one of the standard types. This allows an ABI / compiler to choose the type of an enum depending on the values it needs to store, and storing larger values in it can lead to undefined behaviour. The tx_type and rx_filters members of struct kernel_ethtool_ts_info are defined as enumerated types, but are bit arrays, where each bit is defined by the enumerated type. This means they typically store values in excess of the maximum value of the enumerated type, in fact (1 << max_value) and thus must not be declared using the enumated type. Fix both of these to use u32, as per the corresponding __u32 UAPI type. Fixes: 2111375b85ad ("net: Add struct kernel_ethtool_ts_info") Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Kory Maincent <kory.maincent@bootlin.com> Link: https://patch.msgid.link/E1uvMEK-00000003Amd-2pWR@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org> 2025-09-10selftests/bpf: Skip timer cases when bpf_timer is not supportedLeon Hwang5-0/+20 When enable CONFIG_PREEMPT_RT, verifier will reject bpf_timer with returning -EOPNOTSUPP. Therefore, skip test cases when errno is EOPNOTSUPP. cd tools/testing/selftests/bpf ./test_progs -t timer 125 free_timer:SKIP 456 timer:SKIP 457/1 timer_crash/array:SKIP 457/2 timer_crash/hash:SKIP 457 timer_crash:SKIP 458 timer_lockup:SKIP 459 timer_mim:SKIP Summary: 5/0 PASSED, 6 SKIPPED, 0 FAILED Signed-off-by: Leon Hwang <leon.hwang@linux.dev> Link: https://lore.kernel.org/r/20250910125740.52172-3-leon.hwang@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org> 2025-09-10bpf: Reject bpf_timer for PREEMPT_RTLeon Hwang1-0/+4 When enable CONFIG_PREEMPT_RT, the kernel will warn when run timer selftests by './test_progs -t timer': BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 In order to avoid such warning, reject bpf_timer in verifier when PREEMPT_RT is enabled. Signed-off-by: Leon Hwang <leon.hwang@linux.dev> Link: https://lore.kernel.org/r/20250910125740.52172-2-leon.hwang@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org> 2025-09-10libceph: fix invalid accesses to ceph_connection_v1_infoIlya Dryomov1-3/+4 There is a place where generic code in messenger.c is reading and another place where it is writing to con->v1 union member without checking that the union member is active (i.e. msgr1 is in use). On 64-bit systems, con->v1.auth_retry overlaps with con->v2.out_iter, so such a read is almost guaranteed to return a bogus value instead of 0 when msgr2 is in use. This ends up being fairly benign because the side effect is just the invalidation of the authorizer and successive fetching of new tickets. con->v1.connect_seq overlaps with con->v2.conn_bufs and the fact that it's being written to can cause more serious consequences, but luckily it's not something that happens often. Cc: stable@vger.kernel.org Fixes: cd1a677cad99 ("libceph, ceph: implement msgr2.1 protocol (crc and secure modes)") Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Reviewed-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com> 2025-09-10PM: hibernate: Restrict GFP mask in hibernation_snapshot()Rafael J. Wysocki1-0/+1 Commit 12ffc3b1513e ("PM: Restrict swap use to later in the suspend sequence") incorrectly removed a pm_restrict_gfp_mask() call from hibernation_snapshot(), so memory allocations involving swap are not prevented from being carried out in this code path any more which may lead to serious breakage. The symptoms of such breakage have become visible after adding a shrink_shmem_memory() call to hibernation_snapshot() in commit 2640e819474f ("PM: hibernate: shrink shmem pages after dev_pm_ops.prepare()") which caused this problem to be much more likely to manifest itself. However, since commit 2640e819474f was initially present in the DRM tree that did not include commit 12ffc3b1513e, the symptoms of this issue were not visible until merge commit 260f6f4fda93 ("Merge tag 'drm-next-2025-07-30' of https://gitlab.freedesktop.org/drm/kernel") that exposed it through an entirely reasonable merge conflict resolution. Fixes: 12ffc3b1513e ("PM: Restrict swap use to later in the suspend sequence") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220555 Reported-by: Todd Brandt <todd.e.brandt@linux.intel.com> Tested-by: Todd Brandt <todd.e.brandt@linux.intel.com> Cc: 6.16+ <stable@vger.kernel.org> # 6.16+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> 2025-09-10MAINTAINERS: add Phil as netfilter reviewerFlorian Westphal1-0/+1 Phil has contributed to netfilter with features, fixes and patch reviews for a long time. Make this more formal and add Reviewer tag. Acked-by: Jozsef Kadlecsik <kadlec@netfilter.org> Acked-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Florian Westphal <fw@strlen.de> 2025-09-10netfilter: nf_tables: restart set lookup on base_seq changeFlorian Westphal2-2/+32 The hash, hash_fast, rhash and bitwise sets may indicate no result even though a matching element exists during a short time window while other cpu is finalizing the transaction. This happens when the hash lookup/bitwise lookup function has picked up the old genbit, right before it was toggled by nf_tables_commit(), but then the same cpu managed to unlink the matching old element from the hash table: cpu0 cpu1 has added new elements to clone has marked elements as being inactive in new generation perform lookup in the set enters commit phase: A) observes old genbit increments base_seq I) increments the genbit II) removes old element from the set B) finds matching element C) returns no match: found element is not valid in old generation Next lookup observes new genbit and finds matching e2. Consider a packet matching element e1, e2. cpu0 processes following transaction: 1. remove e1 2. adds e2, which has same key as e1. P matches both e1 and e2. Therefore, cpu1 should always find a match for P. Due to above race, this is not the case: cpu1 observed the old genbit. e2 will not be considered once it is found. The element e1 is not found anymore if cpu0 managed to unlink it from the hlist before cpu1 found it during list traversal. The situation only occurs for a brief time period, lookups happening after I) observe new genbit and return e2. This problem exists in all set types except nft_set_pipapo, so fix it once in nft_lookup rather than each set ops individually. Sample the base sequence counter, which gets incremented right before the genbit is changed. Then, if no match is found, retry the lookup if the base sequence was altered in between. If the base sequence hasn't changed: - No update took place: no-match result is expected. This is the common case. or: - nf_tables_commit() hasn't progressed to genbit update yet. Old elements were still visible and nomatch result is expected, or: - nf_tables_commit updated the genbit: We picked up the new base_seq, so the lookup function also picked up the new genbit, no-match result is expected. If the old genbit was observed, then nft_lookup also picked up the old base_seq: nft_lookup_should_retry() returns true and relookup is performed in the new generation. This problem was added when the unconditional synchronize_rcu() call that followed the current/next generation bit toggle was removed. Thanks to Pablo Neira Ayuso for reviewing an earlier version of this patchset, for suggesting re-use of existing base_seq and placement of the restart loop in nft_set_do_lookup(). Fixes: 0cbc06b3faba ("netfilter: nf_tables: remove synchronize_rcu in commit phase") Signed-off-by: Florian Westphal <fw@strlen.de> 2025-09-10netfilter: nf_tables: make nft_set_do_lookup available unconditionallyFlorian Westphal2-13/+14 This function was added for retpoline mitigation and is replaced by a static inline helper if mitigations are not enabled. Enable this helper function unconditionally so next patch can add a lookup restart mechanism to fix possible false negatives while transactions are in progress. Adding lookup restarts in nft_lookup_eval doesn't work as nft_objref would then need the same copypaste loop. This patch is separate to ease review of the actual bug fix. Suggested-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Florian Westphal <fw@strlen.de> 2025-09-10netfilter: nf_tables: place base_seq in struct netFlorian Westphal3-33/+34 This will soon be read from packet path around same time as the gencursor. Both gencursor and base_seq get incremented almost at the same time, so it makes sense to place them in the same structure. This doesn't increase struct net size on 64bit due to padding. Signed-off-by: Florian Westphal <fw@strlen.de> 2025-09-10netfilter: nft_set_rbtree: continue traversal if element is inactiveFlorian Westphal1-3/+3 When the rbtree lookup function finds a match in the rbtree, it sets the range start interval to a potentially inactive element. Then, after tree lookup, if the matching element is inactive, it returns NULL and suppresses a matching result. This is wrong and leads to false negative matches when a transaction has already entered the commit phase. cpu0 cpu1 has added new elements to clone has marked elements as being inactive in new generation perform lookup in the set enters commit phase: I) increments the genbit A) observes new genbit B) finds matching range C) returns no match: found range invalid in new generation II) removes old elements from the tree C New nft_lookup happening now will find matching element, because it is no longer obscured by old, inactive one. Consider a packet matching range r1-r2: cpu0 processes following transaction: 1. remove r1-r2 2. add r1-r3 P is contained in both ranges. Therefore, cpu1 should always find a match for P. Due to above race, this is not the case: cpu1 does find r1-r2, but then ignores it due to the genbit indicating the range has been removed. It does NOT test for further matches. The situation persists for all lookups until after cpu0 hits II) after which r1-r3 range start node is tested for the first time. Move the "interval start is valid" check ahead so that tree traversal continues if the starting interval is not valid in this generation. Thanks to Stefan Hanreich for providing an initial reproducer for this bug. Reported-by: Stefan Hanreich <s.hanreich@proxmox.com> Fixes: c1eda3c6394f ("netfilter: nft_rbtree: ignore inactive matching element with no descendants") Signed-off-by: Florian Westphal <fw@strlen.de> 2025-09-10netfilter: nft_set_pipapo: don't check genbit from packetpath lookupsFlorian Westphal2-5/+19 The pipapo set type is special in that it has two copies of its datastructure: one live copy containing only valid elements and one on-demand clone used during transaction where adds/deletes happen. This clone is not visible to the datapath. This is unlike all other set types in nftables, those all link new elements into their live hlist/tree. For those sets, the lookup functions must skip the new elements while the transaction is ongoing to ensure consistency. As the clone is shallow, removal does have an effect on the packet path: once the transaction enters the commit phase the 'gencursor' bit that determines which elements are active and which elements should be ignored (because they are no longer valid) is flipped. This causes the datapath lookup to ignore these elements if they are found during lookup. This opens up a small race window where pipapo has an inconsistent view of the dataset from when the transaction-cpu flipped the genbit until the transaction-cpu calls nft_pipapo_commit() to swap live/clone pointers: cpu0 cpu1 has added new elements to clone has marked elements as being inactive in new generation perform lookup in the set enters commit phase: I) increments the genbit A) observes new genbit removes elements from the clone so they won't be found anymore B) lookup in datastructure can't see new elements yet, but old elements are ignored -> Only matches elements that were not changed in the transaction II) calls nft_pipapo_commit(), clone and live pointers are swapped. C New nft_lookup happening now will find matching elements. Consider a packet matching range r1-r2: cpu0 processes following transaction: 1. remove r1-r2 2. add r1-r3 P is contained in both ranges. Therefore, cpu1 should always find a match for P. Due to above race, this is not the case: cpu1 does find r1-r2, but then ignores it due to the genbit indicating the range has been removed. At the same time, r1-r3 is not visible yet, because it can only be found in the clone. The situation persists for all lookups until after cpu0 hits II). The fix is easy: Don't check the genbit from pipapo lookup functions. This is possible because unlike the other set types, the new elements are not reachable from the live copy of the dataset. The clone/live pointer swap is enough to avoid matching on old elements while at the same time all new elements are exposed in one go. After this change, step B above returns a match in r1-r2. This is fine: r1-r2 only becomes truly invalid the moment they get freed. This happens after a synchronize_rcu() call and rcu read lock is held via netfilter hook traversal (nf_hook_slow()). Cc: Stefano Brivio <sbrivio@redhat.com> Fixes: 3c4287f62044 ("nf_tables: Add set type for arbitrary concatenation of ranges") Signed-off-by: Florian Westphal <fw@strlen.de> 2025-09-10netfilter: nft_set_bitmap: fix lockdep splat due to missing annotationFlorian Westphal1-1/+2 Running new 'set_flush_add_atomic_bitmap' test case for nftables.git with CONFIG_PROVE_RCU_LIST=y yields: net/netfilter/nft_set_bitmap.c:231 RCU-list traversed in non-reader section!! rcu_scheduler_active = 2, debug_locks = 1 1 lock held by nft/4008: #0: ffff888147f79cd8 (&nft_net->commit_mutex){+.+.}-{4:4}, at: nf_tables_valid_genid+0x2f/0xd0 lockdep_rcu_suspicious+0x116/0x160 nft_bitmap_walk+0x22d/0x240 nf_tables_delsetelem+0x1010/0x1a00 .. This is a false positive, the list cannot be altered while the transaction mutex is held, so pass the relevant argument to the iterator. Fixes tag intentionally wrong; no point in picking this up if earlier false-positive-fixups were not applied. Fixes: 28b7a6b84c0a ("netfilter: nf_tables: avoid false-positive lockdep splats in set walker") Signed-off-by: Florian Westphal <fw@strlen.de> 2025-09-10can: rcar_can: rcar_can_resume(): fix s2ram with PSCIGeert Uytterhoeven1-7/+1 On R-Car Gen3 using PSCI, s2ram powers down the SoC. After resume, the CAN interface no longer works, until it is brought down and up again. Fix this by calling rcar_can_start() from the PM resume callback, to fully initialize the controller instead of just restarting it. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/699b2f7fcb60b31b6f976a37f08ce99c5ffccb31.1755165227.git.geert+renesas@glider.be Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> 2025-09-10can: xilinx_can: xcan_write_frame(): fix use-after-free of transmitted SKBAnssi Hannula1-8/+8 can_put_echo_skb() takes ownership of the SKB and it may be freed during or after the call. However, xilinx_can xcan_write_frame() keeps using SKB after the call. Fix that by only calling can_put_echo_skb() after the code is done touching the SKB. The tx_lock is held for the entire xcan_write_frame() execution and also on the can_get_echo_skb() side so the order of operations does not matter. An earlier fix commit 3d3c817c3a40 ("can: xilinx_can: Fix usage of skb memory") did not move the can_put_echo_skb() call far enough. Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi> Fixes: 1598efe57b3e ("can: xilinx_can: refactor code in preparation for CAN FD support") Link: https://patch.msgid.link/20250822095002.168389-1-anssi.hannula@bitwise.fi [mkl: add "commit" in front of sha1 in patch description] [mkl: fix indention] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> 2025-09-10can: j1939: j1939_local_ecu_get(): undo increment when j1939_local_ecu_get() ↵Tetsuo Handa1-1/+4 fails Since j1939_sk_bind() and j1939_sk_release() call j1939_local_ecu_put() when J1939_SOCK_BOUND was already set, but the error handling path for j1939_sk_bind() will not set J1939_SOCK_BOUND when j1939_local_ecu_get() fails, j1939_local_ecu_get() needs to undo priv->ents[sa].nusers++ when j1939_local_ecu_get() returns an error. Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Tested-by: Oleksij Rempel <o.rempel@pengutronix.de> Acked-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://patch.msgid.link/e7f80046-4ff7-4ce2-8ad8-7c3c678a42c9@I-love.SAKURA.ne.jp Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> 2025-09-10can: j1939: j1939_sk_bind(): call j1939_priv_put() immediately when ↵Tetsuo Handa1-0/+3 j1939_local_ecu_get() failed Commit 25fe97cb7620 ("can: j1939: move j1939_priv_put() into sk_destruct callback") expects that a call to j1939_priv_put() can be unconditionally delayed until j1939_sk_sock_destruct() is called. But a refcount leak will happen when j1939_sk_bind() is called again after j1939_local_ecu_get() from previous j1939_sk_bind() call returned an error. We need to call j1939_priv_put() before j1939_sk_bind() returns an error. Fixes: 25fe97cb7620 ("can: j1939: move j1939_priv_put() into sk_destruct callback") Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Tested-by: Oleksij Rempel <o.rempel@pengutronix.de> Acked-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://patch.msgid.link/4f49a1bc-a528-42ad-86c0-187268ab6535@I-love.SAKURA.ne.jp Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> 2025-09-10can: j1939: implement NETDEV_UNREGISTER notification handlerTetsuo Handa3-0/+53 syzbot is reporting unregister_netdevice: waiting for vcan0 to become free. Usage count = 2 problem, for j1939 protocol did not have NETDEV_UNREGISTER notification handler for undoing changes made by j1939_sk_bind(). Commit 25fe97cb7620 ("can: j1939: move j1939_priv_put() into sk_destruct callback") expects that a call to j1939_priv_put() can be unconditionally delayed until j1939_sk_sock_destruct() is called. But we need to call j1939_priv_put() against an extra ref held by j1939_sk_bind() call (as a part of undoing changes made by j1939_sk_bind()) as soon as NETDEV_UNREGISTER notification fires (i.e. before j1939_sk_sock_destruct() is called via j1939_sk_release()). Otherwise, the extra ref on "struct j1939_priv" held by j1939_sk_bind() call prevents "struct net_device" from dropping the usage count to 1; making it impossible for unregister_netdevice() to continue. Reported-by: syzbot <syzbot+881d65229ca4f9ae8c84@syzkaller.appspotmail.com> Closes: https://syzkaller.appspot.com/bug?extid=881d65229ca4f9ae8c84 Tested-by: syzbot <syzbot+881d65229ca4f9ae8c84@syzkaller.appspotmail.com> Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Fixes: 25fe97cb7620 ("can: j1939: move j1939_priv_put() into sk_destruct callback") Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Tested-by: Oleksij Rempel <o.rempel@pengutronix.de> Acked-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://patch.msgid.link/ac9db9a4-6c30-416e-8b94-96e6559d55b2@I-love.SAKURA.ne.jp [mkl: remove space in front of label] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>