summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-07-22selftests/futex: Define SYS_futex on 32-bit architectures with 64-bit time_tCynthia Huang
The kernel does not provide sys_futex() on 32-bit architectures that do not support 32-bit time representations, such as riscv32. As a result, glibc cannot define SYS_futex, causing compilation failures in tests that rely on this syscall. Define SYS_futex as SYS_futex_time64 in such cases to ensure successful compilation and compatibility. Signed-off-by: Cynthia Huang <cynthia@andestech.com> Signed-off-by: Ben Zong-You Xie <ben717@andestech.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Muhammad Usama Anjum <usama.anjum@collabora.com> Link: https://lore.kernel.org/all/20250710103630.3156130-1-ben717@andestech.com
2025-07-22sched/idle: Remove play_idle()Feng Lee
play_idle() is no longer in use, so delete it. Signed-off-by: Feng Lee <379943137@qq.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/tencent_C3E0BD9B812C27A30FC49F1EA6A4B1352707@qq.com
2025-07-22rust: io: fix broken intra-doc links to `platform::Device`Miguel Ojeda
`platform` is not accessible from here. Thus fix the intra-doc links by qualifying the paths a bit more. Fixes: 1d0d4b28513b ("rust: io: mem: add a generic iomem abstraction") Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Link: https://lore.kernel.org/r/20250722085500.1360401-2-ojeda@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-07-22rust: io: fix broken intra-doc link to missing `flags` moduleMiguel Ojeda
There is no `mod flags` in this case, unlike others. Instead, they are associated constants for the `Flags` type. Thus reword the sentence to fix the broken intra-doc link, providing an example of constant and linking to it to clarify which ones we are referring to. Fixes: 493fc33ec252 ("rust: io: add resource abstraction") Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Link: https://lore.kernel.org/r/20250722085500.1360401-1-ojeda@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-07-22arch/powerpc: Remove .interp section in vmlinuxChristophe Leroy
When building with CONFIG_RELOCATABLE, there is a .interp section which contains the name of the expected ELF interpreter: Contents of section .interp: c0000000021c1bac 2f757372 2f6c6962 2f6c642e 736f2e31 /usr/lib/ld.so.1 c0000000021c1bbc 00 . That information is useless and even likely wrong. Remove it. Link: https://github.com/linuxppc/issues/issues/434 Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Acked-by: Segher Boessenkool <segher@kernel.crashing.org> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/eeaf8fd6628a75d19872ab31cf7e7179e2baef5e.1751366959.git.christophe.leroy@csgroup.eu
2025-07-22powerpc: Drop GPL boilerplate text with obsolete FSF addressThomas Huth
The FSF does not reside in the Franklin street anymore, so we should not request the people to write to this address. Fortunately, these header files already contain a proper SPDX license identifier, so it should be fine to simply drop all of this license boilerplate code here. Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250711072553.198777-1-thuth@redhat.com
2025-07-22powerpc: Don't use %pK through printkThomas Weißschuh
In the past %pK was preferable to %p as it would not leak raw pointer values into the kernel log. Since commit ad67b74d2469 ("printk: hash addresses printed with %p") the regular %p has been improved to avoid this issue. Furthermore, restricted pointers ("%pK") were never meant to be used through printk(). They can still unintentionally leak raw pointers or acquire sleeping locks in atomic contexts. Switch to the regular pointer formatting which is safer and easier to reason about. Link: https://lore.kernel.org/lkml/20250113171731-dc10e3c1-da64-4af0-b767-7c7070468023@linutronix.de/ Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250718-restricted-pointers-powerpc-v2-1-fd7bddd809f3@linutronix.de
2025-07-22wifi: mac80211: don't require cipher and keylen in gtk rekeyMiri Korenblit
ieee80211_add_gtk_rekey receives a keyconf as an argument, and the cipher and keylen are taken from there to the new allocated key. But in rekey, both the cipher and the keylen should be the same as of the old key, so let ieee80211_add_gtk_rekey find those, so drivers won't have to fill it in. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250721214922.3c5c023bfae9.Ie6594ae2b4b6d5b3d536e642b349046ebfce7a5d@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-22wifi: nl80211: Set num_sub_specs before looping through sub_specsKees Cook
The processing of the struct cfg80211_sar_specs::sub_specs flexible array requires its counter, num_sub_specs, to be assigned before the loop in nl80211_set_sar_specs(). Leave the final assignment after the loop in place in case fewer ended up in the array. Fixes: aa4ec06c455d ("wifi: cfg80211: use __counted_by where appropriate") Signed-off-by: Kees Cook <kees@kernel.org> Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://patch.msgid.link/20250721183125.work.183-kees@kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-22wifi: mac80211: Write cnt before copying in ieee80211_copy_rnr_beacon()Kees Cook
While I caught the need for setting cnt early in nl80211_parse_rnr_elems() in the original annotation of struct cfg80211_rnr_elems with __counted_by, I missed a similar pattern in ieee80211_copy_rnr_beacon(). Fix this by moving the cnt assignment to before the loop. Fixes: 7b6d7087031b ("wifi: cfg80211: Annotate struct cfg80211_rnr_elems with __counted_by") Signed-off-by: Kees Cook <kees@kernel.org> Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://patch.msgid.link/20250721182521.work.540-kees@kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-22kselftest/arm64: Handle attempts to disable SM on SME only systemsMark Brown
The ABI for disabling streaming mode via ptrace is to do a write via the SVE register set. Following the recent round of fixes to the ptrace code we don't support this operation on systems without SVE, which is detected as failures by fp-ptrace. Update the program so that it knows that this operation is not currently supported. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20250718-arm64-fp-ptrace-sme-only-v1-3-3b96dd19a503@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2025-07-22kselftest/arm64: Fix SVE write data generation for SME only systemsMark Brown
fp-ptrace does not handle SME only systems correctly when generating data, on SME only systems scenarios where we are not in streaming mode will not have an expected vector length. This leads to attempts to do memcpy()s of zero byte arrays which can crash, fix this by skipping generation of SVE data for cases where we do not expect to have an active vector length. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20250718-arm64-fp-ptrace-sme-only-v1-2-3b96dd19a503@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2025-07-22kselftest/arm64: Test SME on SME only systems in fp-ptraceMark Brown
When checking that the vector extensions are supported fp-ptrace currently only checks for SVE being supported which means that we get into a confused half configured state for SME only systems. Check for SME as well. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20250718-arm64-fp-ptrace-sme-only-v1-1-3b96dd19a503@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
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-21scsi: libiscsi: Initialize iscsi_conn->dd_data only if memory is allocatedShowrya M N
In case of an ib_fast_reg_mr allocation failure during iSER setup, the machine hits a panic because iscsi_conn->dd_data is initialized unconditionally, even when no memory is allocated (dd_size == 0). This leads invalid pointer dereference during connection teardown. Fix by setting iscsi_conn->dd_data only if memory is actually allocated. Panic trace: ------------ iser: iser_create_fastreg_desc: Failed to allocate ib_fast_reg_mr err=-12 iser: iser_alloc_rx_descriptors: failed allocating rx descriptors / data buffers BUG: unable to handle page fault for address: fffffffffffffff8 RIP: 0010:swake_up_locked.part.5+0xa/0x40 Call Trace: complete+0x31/0x40 iscsi_iser_conn_stop+0x88/0xb0 [ib_iser] iscsi_stop_conn+0x66/0xc0 [scsi_transport_iscsi] iscsi_if_stop_conn+0x14a/0x150 [scsi_transport_iscsi] iscsi_if_rx+0x1135/0x1834 [scsi_transport_iscsi] ? netlink_lookup+0x12f/0x1b0 ? netlink_deliver_tap+0x2c/0x200 netlink_unicast+0x1ab/0x280 netlink_sendmsg+0x257/0x4f0 ? _copy_from_user+0x29/0x60 sock_sendmsg+0x5f/0x70 Signed-off-by: Showrya M N <showrya@chelsio.com> Signed-off-by: Potnuri Bharat Teja <bharat@chelsio.com> Link: https://lore.kernel.org/r/20250627112329.19763-1-showrya@chelsio.com Reviewed-by: Chris Leech <cleech@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
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-21scsi: scsi_transport_fc: Add comments to describe added 'rport' parameterEwan D. Milne
Note that there is no executable code altered by this patch. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202507181446.aAoFiDm5-lkp@intel.com/ Signed-off-by: Ewan D. Milne <emilne@redhat.com> Link: https://lore.kernel.org/r/20250721164652.335716-1-emilne@redhat.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.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-21Merge tag 'clk-microchip-6.17' of ↵Stephen Boyd
https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux into clk-microchip Microchip clock updates for v6.17 - Fix the PLL output ranges for Microchip SAM9X7, based on the latest hardware documentation updates * tag 'clk-microchip-6.17' of https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux: clk: at91: sam9x7: update pll clk ranges
2025-07-21Merge tag 'thead-clk-for-v6.17' of ↵Stephen Boyd
git://git.kernel.org/pub/scm/linux/kernel/git/fustini/linux into clk-thead Pull T-HEAD TH1520 clk driver updates from Drew Fustini: - Fix the parent data for osc_12m by referencing osc_24m by index. - Mark essential bus clocks as CLK_IGNORE_UNUSED to fix boot hang associated with the PVT sensor. * tag 'thead-clk-for-v6.17' of git://git.kernel.org/pub/scm/linux/kernel/git/fustini/linux: clk: thead: th1520-ap: Correctly refer the parent of osc_12m clk: thead: Mark essential bus clocks as CLK_IGNORE_UNUSED
generated by cgit (git 2.34.1) at 2025-09-17 06:23:43 +0000