summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-07-22kselftest/arm64: Test FPSIMD format data writes via NT_ARM_SVE in fp-ptraceMark Brown
The NT_ARM_SVE register set supports two data formats, the native SVE one and an alternative format where we embed a copy of user_fpsimd_data as used for NT_PRFPREG in the SVE register set. The register data is set as for a write to NT_PRFPREG and changes in vector length and streaming mode are handled as for any NT_ARM_SVE write. This has not previously been tested by fp-ptrace, add coverage of it. We do not support writes in FPSIMD format for NT_ARM_SSVE so we skip the test for anything that would leave us in streaming mode. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20250718-arm64-fp-ptrace-sve-fpsimd-v1-1-7ecda32aa297@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2025-07-22kselftest/arm64: Allow sve-ptrace to run on SME only systemsMark Brown
Currently the sve-ptrace test program only runs if the system supports SVE but since SME includes streaming SVE the tests it offers are valid even on a system that only supports SME. Since the tests already have individual hwcap checks just remove the top level test and rely on those. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20250718-arm64-sve-ptrace-sme-only-v1-1-2a1121e51b1d@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2025-07-22Merge tag 'ath-next-20250721' of ↵Johannes Berg
git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath into wireless-next Jeff Johnson says: ================== ath.git patches for v6.17 Highlights for some specific drivers include: ath9k: Add AHB "of" support ath11k: Support device-specific firmware override Fix potentially reordered access to device memory ath12k: Add more Wi-Fi 7 functionality Add more statistics to DebugFS Support different memory profiles Support 802.11 encap/decap offload to firmware Fix potentially reordered access to device memory And of course there is the usual set of cleanups and bug fixes across the entire family of "ath" drivers. ================== Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-21s390: Handle KCOV __init vs inline mismatchesKees Cook
When KCOV is enabled all functions get instrumented, unless the __no_sanitize_coverage attribute is used. To prepare for __no_sanitize_coverage being applied to __init functions, we have to handle differences in how GCC's inline optimizations get resolved. For s390 this exposed a place where the __init annotation was missing but ended up being "accidentally correct". Fix this cases and force a couple functions to be inline with __always_inline. Acked-by: Heiko Carstens <hca@linux.ibm.com> Link: https://lore.kernel.org/r/20250717232519.2984886-7-kees@kernel.org Signed-off-by: Kees Cook <kees@kernel.org>
2025-07-21arm: Handle KCOV __init vs inline mismatchesKees Cook
When KCOV is enabled all functions get instrumented, unless the __no_sanitize_coverage attribute is used. To prepare for __no_sanitize_coverage being applied to __init functions, we have to handle differences in how GCC's inline optimizations get resolved. For arm this exposed several places where __init annotations were missing but ended up being "accidentally correct". Fix these cases and force several functions to be inline with __always_inline. Acked-by: Nishanth Menon <nm@ti.com> Acked-by: Lee Jones <lee@kernel.org> Reviewed-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20250717232519.2984886-5-kees@kernel.org Signed-off-by: Kees Cook <kees@kernel.org>
2025-07-21mips: Handle KCOV __init vs inline mismatchKees Cook
When KCOV is enabled all functions get instrumented, unless the __no_sanitize_coverage attribute is used. To prepare for __no_sanitize_coverage being applied to __init functions, we have to handle differences in how GCC's inline optimizations get resolved. For mips this requires adding the __init annotation on init_mips_clocksource(). Reviewed-by: Huacai Chen <chenhuacai@loongson.cn> Link: https://lore.kernel.org/r/20250717232519.2984886-9-kees@kernel.org Signed-off-by: Kees Cook <kees@kernel.org>
2025-07-21powerpc/mm/book3s64: Move kfence and debug_pagealloc related calls to __init ↵Ritesh Harjani (IBM)
section Move a few kfence and debug_pagealloc related functions in hash_utils.c and radix_pgtable.c to __init sections since these are only invoked once by an __init function during system initialization. i.e. - hash_debug_pagealloc_alloc_slots() - hash_kfence_alloc_pool() - hash_kfence_map_pool() The above 3 functions only gets called by __init htab_initialize(). - alloc_kfence_pool() - map_kfence_pool() The above 2 functions only gets called by __init radix_init_pgtable() This should also help fix warning msgs like: >> WARNING: modpost: vmlinux: section mismatch in reference: hash_debug_pagealloc_alloc_slots+0xb0 (section: .text) -> memblock_alloc_try_nid (section: .init.text) Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202504190552.mnFGs5sj-lkp@intel.com/ Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Link: https://lore.kernel.org/r/20250717232519.2984886-8-kees@kernel.org Signed-off-by: Kees Cook <kees@kernel.org>
2025-07-21configs/hardening: Enable CONFIG_INIT_ON_FREE_DEFAULT_ONKees Cook
To reduce stale data lifetimes, enable CONFIG_INIT_ON_FREE_DEFAULT_ON as well. This matches the addition of CONFIG_STACKLEAK=y, which is doing similar for stack memory. Link: https://lore.kernel.org/r/20250717232519.2984886-13-kees@kernel.org Signed-off-by: Kees Cook <kees@kernel.org>
2025-07-21configs/hardening: Enable CONFIG_KSTACK_ERASEKees Cook
Since we can wipe the stack with both Clang and GCC plugins, enable this for the "hardening.config" for wider testing. Link: https://lore.kernel.org/r/20250717232519.2984886-12-kees@kernel.org Signed-off-by: Kees Cook <kees@kernel.org>
2025-07-21stackleak: Split KSTACK_ERASE_CFLAGS from GCC_PLUGINS_CFLAGSKees Cook
In preparation for Clang stack depth tracking for KSTACK_ERASE, split the stackleak-specific cflags out of GCC_PLUGINS_CFLAGS into KSTACK_ERASE_CFLAGS. Link: https://lore.kernel.org/r/20250717232519.2984886-3-kees@kernel.org Signed-off-by: Kees Cook <kees@kernel.org>
2025-07-21stackleak: Rename stackleak_track_stack to __sanitizer_cov_stack_depthKees Cook
The Clang stack depth tracking implementation has a fixed name for the stack depth tracking callback, "__sanitizer_cov_stack_depth", so rename the GCC plugin function to match since the plugin has no external dependencies on naming. Link: https://lore.kernel.org/r/20250717232519.2984886-2-kees@kernel.org Signed-off-by: Kees Cook <kees@kernel.org>
2025-07-21stackleak: Rename STACKLEAK to KSTACK_ERASEKees Cook
In preparation for adding Clang sanitizer coverage stack depth tracking that can support stack depth callbacks: - Add the new top-level CONFIG_KSTACK_ERASE option which will be implemented either with the stackleak GCC plugin, or with the Clang stack depth callback support. - Rename CONFIG_GCC_PLUGIN_STACKLEAK as needed to CONFIG_KSTACK_ERASE, but keep it for anything specific to the GCC plugin itself. - Rename all exposed "STACKLEAK" names and files to "KSTACK_ERASE" (named for what it does rather than what it protects against), but leave as many of the internals alone as possible to avoid even more churn. While here, also split "prev_lowest_stack" into CONFIG_KSTACK_ERASE_METRICS, since that's the only place it is referenced from. Suggested-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20250717232519.2984886-1-kees@kernel.org Signed-off-by: Kees Cook <kees@kernel.org>
2025-07-22wifi: iwlwifi: mvm/fw: Avoid -Wflex-array-member-not-at-end warningsGustavo A. R. Silva
-Wflex-array-member-not-at-end was introduced in GCC-14, and we are getting ready to enable it, globally. We have a flexible struct iwl_tx_cmd_v6 in the middle of a few structs, but those don't even need the flexible part. So, we add iwl_tx_cmd_v6_params, that will contain everything except the flexible array and use this one for the containing structs. Also, as part of the refactoring remove unused flex array `payload`. So, with these changes, fix the following warnings: drivers/net/wireless/intel/iwlwifi/mld/../fw/api/tdls.h:134:27: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/intel/iwlwifi/mld/../fw/api/tdls.h:53:27: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/intel/iwlwifi/mld/../fw/api/tx.h:745:27: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/intel/iwlwifi/mld/../fw/api/tx.h:764:27: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/intel/iwlwifi/mvm/../fw/api/tdls.h:134:27: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/intel/iwlwifi/mvm/../fw/api/tdls.h:53:27: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/intel/iwlwifi/mvm/../fw/api/tx.h:745:27: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/intel/iwlwifi/mvm/../fw/api/tx.h:764:27: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://msgid.link/aCUOQ6wdD1jQjO36@kspp [use iwl_tx_cmd_v6_params as described in the changed commit message] Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709224608.0785a61b0826.I6da02c2a12a5ed1e6d317045a6995d132850a455@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2025-07-22wifi: iwlwifi: Fix typo "ransport"WangYuli
There is a spelling mistake of 'ransport' in comments which should be 'transport'. Link: https://lore.kernel.org/all/03DFEDFFB5729C96+20250714104736.559226-1-wangyuli@uniontech.com/ Signed-off-by: WangYuli <wangyuli@uniontech.com> Link: https://patch.msgid.link/8F065DF7EF7EEB89+20250715055828.932160-1-wangyuli@uniontech.com Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2025-07-22wifi: iwlwifi: fix cmd length when sending WOWLAN_TSC_RSC_PARAMAntonio Quartulli
In iwl_mvm_wowlan_config_rsc_tsc() when calling iwl_mvm_send_cmd_pdu() we are accidentally passing the size of a pointer rather than the size of the object pointed by it. Fix the expression in order to pass the approriate object length. Fixes: 493681d9f95b ("wifi: iwlwifi: remove support of version 4 of iwl_wowlan_rsc_tsc_params_cmd") Address-Coverity-ID: 1647627 ("Incorrect expression (SIZEOF_MISMATCH)") Signed-off-by: Antonio Quartulli <antonio@mandelbit.com> Link: https://patch.msgid.link/20250716201911.700-1-antonio@mandelbit.com Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2025-07-21lib/crypto: tests: Annotate worker to be on stackGuenter Roeck
The following warning traceback is seen if object debugging is enabled with the new crypto test code. ODEBUG: object 9000000106237c50 is on stack 9000000106234000, but NOT annotated. ------------[ cut here ]------------ WARNING: lib/debugobjects.c:655 at lookup_object_or_alloc.part.0+0x19c/0x1f4, CPU#0: kunit_try_catch/468 ... This also results in a boot stall when running the code in qemu:loongarch. Initializing the worker with INIT_WORK_ONSTACK() fixes the problem. Fixes: 950a81224e8b ("lib/crypto: tests: Add hash-test-template.h and gen-hash-testvecs.py") Signed-off-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20250721231917.3182029-1-linux@roeck-us.net Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2025-07-21Merge branch 'ethtool-rss-support-creating-and-removing-contexts-via-netlink'Jakub Kicinski
Jakub Kicinski says: ==================== ethtool: rss: support creating and removing contexts via Netlink This series completes support of RSS configuration via Netlink. All functionality supported by the IOCTL is now supported by Netlink. Future series (time allowing) will add: - hashing on the flow label, which started this whole thing; - pinning the RSS context to a Netlink socket for auto-cleanup. The first patch is a leftover held back from previous series to avoid conflicting with Gal's fix. Next 4 patches refactor existing code to make reusing it for context creation possible. 2 patches after that add create and delete commands. Last but not least the test is extended. ==================== Link: https://patch.msgid.link/20250717234343.2328602-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-21selftests: drv-net: rss_api: context create and delete testsJakub Kicinski
Add test cases for creating and deleting contexts. TAP version 13 1..12 ok 1 rss_api.test_rxfh_nl_set_fail ok 2 rss_api.test_rxfh_nl_set_indir ok 3 rss_api.test_rxfh_nl_set_indir_ctx ok 4 rss_api.test_rxfh_indir_ntf ok 5 rss_api.test_rxfh_indir_ctx_ntf ok 6 rss_api.test_rxfh_nl_set_key ok 7 rss_api.test_rxfh_fields ok 8 rss_api.test_rxfh_fields_set ok 9 rss_api.test_rxfh_fields_set_xfrm # SKIP no input-xfrm supported ok 10 rss_api.test_rxfh_fields_ntf ok 11 rss_api.test_rss_ctx_add ok 12 rss_api.test_rss_ctx_ntf # Totals: pass:11 fail:0 xfail:0 xpass:0 skip:1 error:0 Link: https://patch.msgid.link/20250717234343.2328602-9-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-21ethtool: rss: support removing contexts via NetlinkJakub Kicinski
Implement removing additional RSS contexts via Netlink. Technically it'd be possible to shoehorn the delete operation into ethnl_request_ops-compatible handler. The code ends up longer than open coded version, and I think we'll need a custom way of sending notifications at some stage (if we allow tying the context lifetime to the netlink socket, in the future). Link: https://patch.msgid.link/20250717234343.2328602-8-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-21ethtool: rss: support creating contexts via NetlinkJakub Kicinski
Support creating contexts via Netlink. Setting flow hashing fields on the new context is not supported at this stage, it can be added later. An empty indirection table is not supported. This is a carry over from the IOCTL interface where empty indirection table meant delete. We can repurpose empty indirection table in Netlink but for now to avoid confusion reject it using the policy. Support letting user choose the ID for the new context. This was not possible in IOCTL since the context ID field for the create action had to be set to the ETH_RXFH_CONTEXT_ALLOC magic value. Link: https://patch.msgid.link/20250717234343.2328602-7-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-21ethtool: move ethtool_rxfh_ctx_alloc() to common codeJakub Kicinski
Move ethtool_rxfh_ctx_alloc() to common code, Netlink will need it. Reviewed-by: Gal Pressman <gal@nvidia.com> Link: https://patch.msgid.link/20250717234343.2328602-6-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-21ethtool: rss: factor out populating response from contextJakub Kicinski
Similarly to previous change, factor out populating the response. We will use this after the context was allocated to send a notification so this time factor out from the additional context handling, rather than context 0 handling (for request context didn't exist, for response it does). Reviewed-by: Gal Pressman <gal@nvidia.com> Link: https://patch.msgid.link/20250717234343.2328602-5-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-21ethtool: rss: factor out allocating memory for responseJakub Kicinski
To ease the code reuse for RSS_CREATE we'll want to prepare struct rss_reply_data for the new context. Unfortunately we can't depend on the exiting scaffolding because the context doesn't exist (ctx=NULL) when we start preparing. Factor out the portion of the context 0 handling responsible for allocation of request memory, so that we can call it directly. Link: https://patch.msgid.link/20250717234343.2328602-4-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-21ethtool: rejig the RSS notification machinery for more typesJakub Kicinski
In anticipation for CREATE and DELETE notifications - explicitly pass the notification type to ethtool_rss_notify(), when calling from the IOCTL code. Reviewed-by: Gal Pressman <gal@nvidia.com> Link: https://patch.msgid.link/20250717234343.2328602-3-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-21ethtool: assert that drivers with sym hash are consistent for RSS contextsJakub Kicinski
Supporting per-RSS context configuration of hashing fields but not the hashing algorithm would complicate the code a lot. We'd need to cross check the config against all RSS contexts. None of the drivers need this today, so explicitly prevent new drivers with such skewed capabilities from registering. If such driver appears it will need to first adjust the checks in the core. Link: https://patch.msgid.link/20250717234343.2328602-2-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-21Merge branch 'mptcp-add-tcp_maxseg-sockopt-support'Jakub Kicinski
Matthieu Baerts says: ==================== mptcp: add TCP_MAXSEG sockopt support The TCP_MAXSEG socket option was not supported by MPTCP, mainly because it has never been requested before. But there are still valid use-cases, e.g. with HAProxy. - Patch 1 is a small cleanup patch in the MPTCP sockopt file. - Patch 2 expose some code from TCP, to avoid duplicating it in MPTCP. - Patch 3 adds TCP_MAXSEG sockopt support in MPTCP. - Patch 4 is not related to the others, it fixes a typo in a comment. Note that the new TCP_MAXSEG sockopt support has been validated by a new packetdrill script on the MPTCP CI: https://github.com/multipath-tcp/packetdrill/pull/161 v1: https://lore.kernel.org/20250716-net-next-mptcp-tcp_maxseg-v1-0-548d3a5666f6@kernel.org ==================== Link: https://patch.msgid.link/20250719-net-next-mptcp-tcp_maxseg-v2-0-8c910fbc5307@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-21mptcp: fix typo in a commentmoyuanhao
This patch fixes the follow spelling mistake in a comment: greter -> greater Signed-off-by: moyuanhao <moyuanhao3676@163.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250719-net-next-mptcp-tcp_maxseg-v2-4-8c910fbc5307@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-21mptcp: add TCP_MAXSEG sockopt supportGeliang Tang
The TCP_MAXSEG socket option is currently not supported by MPTCP, mainly because it has never been requested before. But there are still valid use-cases, e.g. with HAProxy. This patch adds its support in MPTCP by propagating the value to all subflows. The get part looks at the value on the first subflow, to be as closed as possible to TCP. Only one value can be returned for the cached MSS, so this can come only from one subflow. Similar to mptcp_setsockopt_first_sf_only(), a generic helper mptcp_setsockopt_all_subflows() is added to set sockopt for each subflows of the mptcp socket. Add a new member for struct mptcp_sock to store the TCP_MAXSEG value, and return this value in getsockopt. Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/515 Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250719-net-next-mptcp-tcp_maxseg-v2-3-8c910fbc5307@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-21tcp: add tcp_sock_set_maxsegGeliang Tang
Add a helper tcp_sock_set_maxseg() to directly set the TCP_MAXSEG sockopt from kernel space. This new helper will be used in the following patch from MPTCP. Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn> Acked-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250719-net-next-mptcp-tcp_maxseg-v2-2-8c910fbc5307@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-21mptcp: sockopt: drop redundant tcp_getsockoptGeliang Tang
tcp_getsockopt() is called twice in mptcp_getsockopt_first_sf_only() in different conditions, which makes the code a bit redundant. The first call to tcp_getsockopt() when the first subflow exists can be replaced by going to a new label "get" before the second call. Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250719-net-next-mptcp-tcp_maxseg-v2-1-8c910fbc5307@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-21s390/qeth: Make hw_trap sysfs attribute idempotentAswin Karuvally
Update qeth driver to allow writing an existing value to the "hw_trap" sysfs attribute. Attempting such a write earlier resulted in -EINVAL. In other words, make the sysfs attribute idempotent. After: $ cat hw_trap disarm $ echo disarm > hw_trap $ Suggested-by: Alexandra Winter <wintera@linux.ibm.com> Signed-off-by: Aswin Karuvally <aswin@linux.ibm.com> Reviewed-by: Alexandra Winter <wintera@linux.ibm.com> Signed-off-by: Alexandra Winter <wintera@linux.ibm.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250718141711.1141049-1-wintera@linux.ibm.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-21net: phy: qcom: qca807x: Enable WoL support using shared libraryLuo Jie
The Wake-on-LAN (WoL) functionality for the QCA807x series is identical to that of the AT8031. WoL support for QCA807x is enabled by utilizing the at8031_set_wol() function provided in the shared library. Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by: Luo Jie <quic_luoj@quicinc.com> Link: https://patch.msgid.link/20250718-qca807x_wol_support-v1-1-cfe323cbb4e8@quicinc.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-21net: usb: smsc95xx: add support for ethtool pause parametersOleksij Rempel
Implement ethtool .get_pauseparam and .set_pauseparam handlers for configuring flow control on smsc95xx. The driver now supports enabling or disabling transmit and receive pause frames, with or without autonegotiation. Pause settings are applied during link-up based on current PHY state and user configuration. Previously, the driver used phy_get_pause() during link-up handling, but lacked initialization and an ethtool interface to configure pause modes. As a result, flow control support was effectively non-functional. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250718075157.297923-1-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-21bpf: Use ERR_CAST instead of ERR_PTR(PTR_ERR(...))Yonghong Song
Intel linux test robot reported a warning that ERR_CAST can be used for error pointer casting instead of more-complicated/rarely-used ERR_PTR(PTR_ERR(...)) style. There is no functionality change, but still let us replace two such instances as it improves consistency and readability. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202507201048.bceHy8zX-lkp@intel.com/ Signed-off-by: Yonghong Song <yonghong.song@linux.dev> Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://patch.msgid.link/20250720164754.3999140-1-yonghong.song@linux.dev
2025-07-21Merge branch '200GbE' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2025-07-18 (idpf, ice, igc, igbvf, ixgbevf) For idpf: Ahmed and Sudheer add support for flow steering via ntuple filters. Current support is for IPv4 and TCP/UDP only. Milena adds support for cross timestamping. Ahmed preserves coalesce settings across resets. For ice: Alex adds reporting of 40GbE speed in devlink port split. Dawid adds support for E835 devices. Jesse refactors profile ptype processing for cleaner, more readable, code. Dave adds a couple of helper functions for LAG to reduce code duplication. For igc: Siang adds support to configure "Default Queue" during runtime using ethtool's Network Flow Classification (NFC) wildcard rule approach. For igbvf: Yuto Ohnuki removes unused fields from igbvf_adapter. For ixgbevf: Yuto Ohnuki removes unused fields from ixgbevf_adapter. * '200GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue: ixgbevf: remove unused fields from struct ixgbevf_adapter igbvf: remove unused fields from struct igbvf_adapter igc: Add wildcard rule support to ethtool NFC using Default Queue igc: Relocate RSS field definitions to igc_defines.h ice: breakout common LAG code into helpers ice: convert ice_add_prof() to bitmap ice: add E835 device IDs ice: add 40G speed to Admin Command GET PORT OPTION idpf: preserve coalescing settings across resets idpf: add cross timestamping idpf: add flow steering support virtchnl2: add flow steering support virtchnl2: rename enum virtchnl2_cap_rss ==================== Link: https://patch.msgid.link/20250718185118.2042772-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-21gve: Fix stuck TX queue for DQ queue formatPraveen Kaligineedi
gve_tx_timeout was calculating missed completions in a way that is only relevant in the GQ queue format. Additionally, it was attempting to disable device interrupts, which is not needed in either GQ or DQ queue formats. As a result, TX timeouts with the DQ queue format likely would have triggered early resets without kicking the queue at all. This patch drops the check for pending work altogether and always kicks the queue after validating the queue has not seen a TX timeout too recently. Cc: stable@vger.kernel.org Fixes: 87a7f321bb6a ("gve: Recover from queue stall due to missed IRQ") Co-developed-by: Tim Hostetler <thostet@google.com> Signed-off-by: Tim Hostetler <thostet@google.com> Signed-off-by: Praveen Kaligineedi <pkaligineedi@google.com> Signed-off-by: Harshitha Ramamurthy <hramamurthy@google.com> Link: https://patch.msgid.link/20250717192024.1820931-1-hramamurthy@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-21net: usb: cdc-ncm: check for filtering capabilityOliver Neukum
If the decice does not support filtering, filtering must not be used and all packets delivered for the upper layers to sort. Signed-off-by: Oliver Neukum <oneukum@suse.com> Link: https://patch.msgid.link/20250717120649.2090929-1-oneukum@suse.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-21net: stmmac: dwmac-renesas-gbeth: Add PM suspend/resume callbacksBiju Das
Add PM suspend/resume callbacks for RZ/G3E SMARC EVK. The PM deep entry is executed by pressing the SLEEP button and exit from entry is by pressing the power button. Logs: root@smarc-rzg3e:~# PM: suspend entry (deep) Filesystems sync: 0.115 seconds Freezing user space processes Freezing user space processes completed (elapsed 0.002 seconds) OOM killer disabled. Freezing remaining freezable tasks Freezing remaining freezable tasks completed (elapsed 0.001 seconds) printk: Suspending console(s) (use no_console_suspend to debug) NOTICE: BL2: v2.10.5(release):2.10.5/rz_soc_dev-162-g7148ba838 NOTICE: BL2: Built : 14:23:58, Jul 5 2025 NOTICE: BL2: SYS_LSI_MODE: 0x13e06 NOTICE: BL2: SYS_LSI_DEVID: 0x8679447 NOTICE: BL2: SYS_LSI_PRR: 0x0 NOTICE: BL2: Booting BL31 renesas-gbeth 15c30000.ethernet end0: Link is Down Disabling non-boot CPUs ... psci: CPU3 killed (polled 0 ms) psci: CPU2 killed (polled 0 ms) psci: CPU1 killed (polled 0 ms) Enabling non-boot CPUs ... Detected VIPT I-cache on CPU1 GICv3: CPU1: found redistributor 100 region 0:0x0000000014960000 CPU1: Booted secondary processor 0x0000000100 [0x412fd050] CPU1 is up Detected VIPT I-cache on CPU2 GICv3: CPU2: found redistributor 200 region 0:0x0000000014980000 CPU2: Booted secondary processor 0x0000000200 [0x412fd050] CPU2 is up Detected VIPT I-cache on CPU3 GICv3: CPU3: found redistributor 300 region 0:0x00000000149a0000 CPU3: Booted secondary processor 0x0000000300 [0x412fd050] CPU3 is up dwmac4: Master AXI performs fixed burst length 15c30000.ethernet end0: No Safety Features support found 15c30000.ethernet end0: IEEE 1588-2008 Advanced Timestamp supported 15c30000.ethernet end0: configuring for phy/rgmii-id link mode dwmac4: Master AXI performs fixed burst length 15c40000.ethernet end1: No Safety Features support found 15c40000.ethernet end1: IEEE 1588-2008 Advanced Timestamp supported 15c40000.ethernet end1: configuring for phy/rgmii-id link mode OOM killer enabled. Restarting tasks: Starting Restarting tasks: Done random: crng reseeded on system resumption PM: suspend exit 15c30000.ethernet end0: Link is Up - 1Gbps/Full - flow control rx/tx root@smarc-rzg3e:~# ifconfig end0 192.168.10.7 up root@smarc-rzg3e:~# ping 192.168.10.1 PING 192.168.10.1 (192.168.10.1) 56(84) bytes of data. 64 bytes from 192.168.10.1: icmp_seq=1 ttl=64 time=2.05 ms 64 bytes from 192.168.10.1: icmp_seq=2 ttl=64 time=0.928 ms Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://patch.msgid.link/20250717071109.8213-1-biju.das.jz@bp.renesas.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-21net: appletalk: Fix use-after-free in AARP proxy probeKito Xu (veritas501)
The AARP proxy‐probe routine (aarp_proxy_probe_network) sends a probe, releases the aarp_lock, sleeps, then re-acquires the lock. During that window an expire timer thread (__aarp_expire_timer) can remove and kfree() the same entry, leading to a use-after-free. race condition: cpu 0 | cpu 1 atalk_sendmsg() | atif_proxy_probe_device() aarp_send_ddp() | aarp_proxy_probe_network() mod_timer() | lock(aarp_lock) // LOCK!! timeout around 200ms | alloc(aarp_entry) and then call | proxies[hash] = aarp_entry aarp_expire_timeout() | aarp_send_probe() | unlock(aarp_lock) // UNLOCK!! lock(aarp_lock) // LOCK!! | msleep(100); __aarp_expire_timer(&proxies[ct]) | free(aarp_entry) | unlock(aarp_lock) // UNLOCK!! | | lock(aarp_lock) // LOCK!! | UAF aarp_entry !! ================================================================== BUG: KASAN: slab-use-after-free in aarp_proxy_probe_network+0x560/0x630 net/appletalk/aarp.c:493 Read of size 4 at addr ffff8880123aa360 by task repro/13278 CPU: 3 UID: 0 PID: 13278 Comm: repro Not tainted 6.15.2 #3 PREEMPT(full) Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1b0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xc1/0x630 mm/kasan/report.c:521 kasan_report+0xca/0x100 mm/kasan/report.c:634 aarp_proxy_probe_network+0x560/0x630 net/appletalk/aarp.c:493 atif_proxy_probe_device net/appletalk/ddp.c:332 [inline] atif_ioctl+0xb58/0x16c0 net/appletalk/ddp.c:857 atalk_ioctl+0x198/0x2f0 net/appletalk/ddp.c:1818 sock_do_ioctl+0xdc/0x260 net/socket.c:1190 sock_ioctl+0x239/0x6a0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl fs/ioctl.c:892 [inline] __x64_sys_ioctl+0x194/0x200 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcb/0x250 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> Allocated: aarp_alloc net/appletalk/aarp.c:382 [inline] aarp_proxy_probe_network+0xd8/0x630 net/appletalk/aarp.c:468 atif_proxy_probe_device net/appletalk/ddp.c:332 [inline] atif_ioctl+0xb58/0x16c0 net/appletalk/ddp.c:857 atalk_ioctl+0x198/0x2f0 net/appletalk/ddp.c:1818 Freed: kfree+0x148/0x4d0 mm/slub.c:4841 __aarp_expire net/appletalk/aarp.c:90 [inline] __aarp_expire_timer net/appletalk/aarp.c:261 [inline] aarp_expire_timeout+0x480/0x6e0 net/appletalk/aarp.c:317 The buggy address belongs to the object at ffff8880123aa300 which belongs to the cache kmalloc-192 of size 192 The buggy address is located 96 bytes inside of freed 192-byte region [ffff8880123aa300, ffff8880123aa3c0) Memory state around the buggy address: ffff8880123aa200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff8880123aa280: 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc fc >ffff8880123aa300: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8880123aa380: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ffff8880123aa400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ================================================================== Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Kito Xu (veritas501) <hxzene@gmail.com> Link: https://patch.msgid.link/20250717012843.880423-1-hxzene@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-21net: bcmasp: Restore programming of TX map vector registerFlorian Fainelli
On ASP versions v2.x we need to program the TX map vector register to properly exercise end-to-end flow control, otherwise the TX engine can either lock-up, or cause the hardware calculated checksum to be wrong/corrupted when multiple back to back packets are being submitted for transmission. This register defaults to 0, which means no flow control being applied. Fixes: e9f31435ee7d ("net: bcmasp: Add support for asp-v3.0") Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/20250718212242.3447751-1-florian.fainelli@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-21Merge branch 'amd-xgbe-add-hardware-ptp-timestamping'Jakub Kicinski
Raju Rangoju says: ==================== amd-xgbe: add hardware PTP timestamping Remove the hwptp abstraction and associated callbacks from the struct xgbe_hw_if {} and move them to separate file after cleanup. Adds complete support for hardware-based PTP (IEEE 1588) timestamping to the AMD XGBE driver. ==================== Link: https://patch.msgid.link/20250718185628.4038779-1-Raju.Rangoju@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-21amd-xgbe: add hardware PTP timestamping supportRaju Rangoju
Adds complete support for hardware-based PTP (IEEE 1588) timestamping to the AMD XGBE driver. - Initialize and configure the MAC PTP registers based on link speed and reference clock. - Support both 50MHz and 125MHz PTP reference clocks. - Update the driver interface and version data to support PTP clock frequency selection. Signed-off-by: Raju Rangoju <Raju.Rangoju@amd.com> Link: https://patch.msgid.link/20250718185628.4038779-3-Raju.Rangoju@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-21and-xgbe: remove the abstraction for hwptpRaju Rangoju
Remove the hwptp abstraction and associated callbacks from the struct xgbe_hw_if {}. The callback structure was only ever assigned a single function, without null checks. This cleanup inlines the logic and moves all the hwtstamp realted code a separate file, improving readability and maintainance. Signed-off-by: Raju Rangoju <Raju.Rangoju@amd.com> Link: https://patch.msgid.link/20250718185628.4038779-2-Raju.Rangoju@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-22btrfs: send: use fallocate for hole punching with send stream v2Filipe Manana
Currently holes are sent as writes full of zeroes, which results in unnecessarily using disk space at the receiving end and increasing the stream size. In some cases we avoid sending writes of zeroes, like during a full send operation where we just skip writes for holes. But for some cases we fill previous holes with writes of zeroes too, like in this scenario: 1) We have a file with a hole in the range [2M, 3M), we snapshot the subvolume and do a full send. The range [2M, 3M) stays as a hole at the receiver since we skip sending write commands full of zeroes; 2) We punch a hole for the range [3M, 4M) in our file, so that now it has a 2M hole in the range [2M, 4M), and snapshot the subvolume. Now if we do an incremental send, we will send write commands full of zeroes for the range [2M, 4M), removing the hole for [2M, 3M) at the receiver. We could improve cases such as this last one by doing additional comparisons of file extent items (or their absence) between the parent and send snapshots, but that's a lot of code to add plus additional CPU and IO costs. Since the send stream v2 already has a fallocate command and btrfs-progs implements a callback to execute fallocate since the send stream v2 support was added to it, update the kernel to use fallocate for punching holes for V2+ streams. Test coverage is provided by btrfs/284 which is a version of btrfs/007 that exercises send stream v2 instead of v1, using fsstress with random operations and fssum to verify file contents. Link: https://github.com/kdave/btrfs-progs/issues/1001 CC: stable@vger.kernel.org # 6.1+ Reviewed-by: Boris Burkov <boris@bur.io> Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2025-07-21Merge branch 'selftests-mptcp-connect-cover-alt-modes'Jakub Kicinski
Matthieu Baerts says: ==================== selftests: mptcp: connect: cover alt modes mptcp_connect.sh can be executed manually with "-m <MODE>" and "-C" to make sure everything works as expected when using "mmap" and "sendfile" modes instead of "poll", and with the MPTCP checksum support. These modes should be validated, but they are not when the selftests are executed via the kselftest helpers. It means that most CIs validating these selftests, like NIPA for the net development trees and LKFT for the stable ones, are not covering these modes. To fix that, new test programs have been added, simply calling mptcp_connect.sh with the right parameters. The first patch can be backported up to v5.6, and the second one up to v5.14. v1: https://lore.kernel.org/20250714-net-mptcp-sft-connect-alt-v1-0-bf1c5abbe575@kernel.org ==================== Link: https://patch.msgid.link/20250715-net-mptcp-sft-connect-alt-v2-0-8230ddd82454@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-21selftests: mptcp: connect: also cover checksumMatthieu Baerts (NGI0)
The checksum mode has been added a while ago, but it is only validated when manually launching mptcp_connect.sh with "-C". The different CIs were then not validating these MPTCP Connect tests with checksum enabled. To make sure they do, add a new test program executing mptcp_connect.sh with the checksum mode. Fixes: 94d66ba1d8e4 ("selftests: mptcp: enable checksum in mptcp_connect.sh") Cc: stable@vger.kernel.org Reviewed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250715-net-mptcp-sft-connect-alt-v2-2-8230ddd82454@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-21selftests: mptcp: connect: also cover alt modesMatthieu Baerts (NGI0)
The "mmap" and "sendfile" alternate modes for mptcp_connect.sh/.c are available from the beginning, but only tested when mptcp_connect.sh is manually launched with "-m mmap" or "-m sendfile", not via the kselftests helpers. The MPTCP CI was manually running "mptcp_connect.sh -m mmap", but not "-m sendfile". Plus other CIs, especially the ones validating the stable releases, were not validating these alternate modes. To make sure these modes are validated by these CIs, add two new test programs executing mptcp_connect.sh with the alternate modes. Fixes: 048d19d444be ("mptcp: add basic kselftest for mptcp") Cc: stable@vger.kernel.org Reviewed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250715-net-mptcp-sft-connect-alt-v2-1-8230ddd82454@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-22btrfs: unfold transaction aborts when writing dirty block groupsFilipe Manana
We have a single transaction abort call that can be due to an error from one of two calls to update_block_group_item(). Unfold the transaction abort calls so that if they happen we know which update_block_group_item() call failed. Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2025-07-22btrfs: use saner variable type and name to indicate extrefs at add_inode_ref()Filipe Manana
We are using a variable named 'log_ref_ver' of type int to indicate if we are processing an extref item or not, using a value of 1 if so, otherwise 0. This is an odd name and type, so rename it to 'is_extref_item' and change its type to bool. Reviewed-by: Boris Burkov <boris@bur.io> Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2025-07-22btrfs: don't skip remaining extrefs if dir not found during log replayFilipe Manana
During log replay, at add_inode_ref(), if we have an extref item that contains multiple extrefs and one of them points to a directory that does not exist in the subvolume tree, we are supposed to ignore it and process the remaining extrefs encoded in the extref item, since each extref can point to a different parent inode. However when that happens we just return from the function and ignore the remaining extrefs. The problem has been around since extrefs were introduced, in commit f186373fef00 ("btrfs: extended inode refs"), but it's hard to hit in practice because getting extref items encoding multiple extref requires getting a hash collision when computing the offset of the extref's key. The offset if computed like this: key.offset = btrfs_extref_hash(dir_ino, name->name, name->len); and btrfs_extref_hash() is just a wrapper around crc32c(). Fix this by moving to next iteration of the loop when we don't find the parent directory that an extref points to. Fixes: f186373fef00 ("btrfs: extended inode refs") CC: stable@vger.kernel.org # 6.1+ Reviewed-by: Boris Burkov <boris@bur.io> Signed-off-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
generated by cgit (git 2.34.1) at 2025-09-24 11:48:08 +0000