summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-03-04net: ethtool: netlink: Allow NULL nlattrs when getting a phy_deviceMaxime Chevallier
ethnl_req_get_phydev() is used to lookup a phy_device, in the case an ethtool netlink command targets a specific phydev within a netdev's topology. It takes as a parameter a const struct nlattr *header that's used for error handling : if (!phydev) { NL_SET_ERR_MSG_ATTR(extack, header, "no phy matching phyindex"); return ERR_PTR(-ENODEV); } In the notify path after a ->set operation however, there's no request attributes available. The typical callsite for the above function looks like: phydev = ethnl_req_get_phydev(req_base, tb[ETHTOOL_A_XXX_HEADER], info->extack); So, when tb is NULL (such as in the ethnl notify path), we have a nice crash. It turns out that there's only the PLCA command that is in that case, as the other phydev-specific commands don't have a notification. This commit fixes the crash by passing the cmd index and the nlattr array separately, allowing NULL-checking it directly inside the helper. Fixes: c15e065b46dc ("net: ethtool: Allow passing a phy index for some commands") Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Kory Maincent <kory.maincent@bootlin.com> Reported-by: Parthiban Veerasooran <parthiban.veerasooran@microchip.com> Link: https://patch.msgid.link/20250301141114.97204-1-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-04ppp: use IFF_NO_QUEUE in virtual interfacesQingfang Deng
For PPPoE, PPTP, and PPPoL2TP, the start_xmit() function directly forwards packets to the underlying network stack and never returns anything other than 1. So these interfaces do not require a qdisc, and the IFF_NO_QUEUE flag should be set. Introduces a direct_xmit flag in struct ppp_channel to indicate when IFF_NO_QUEUE should be applied. The flag is set in ppp_connect_channel() for relevant protocols. While at it, remove the usused latency member from struct ppp_channel. Signed-off-by: Qingfang Deng <dqfext@gmail.com> Reviewed-by: Toke Høiland-Jørgensen <toke@redhat.com> Link: https://patch.msgid.link/20250301135517.695809-1-dqfext@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-04Merge branch 'eth-fbnic-cleanup-macros-and-string-function'Jakub Kicinski
Lee Trager says: ==================== eth: fbnic: Cleanup macros and string function We have received some feedback that the macros we use for reading FW mailbox attributes are too large in scope and confusing to understanding. Additionally the string function did not provide errors allowing it to silently succeed. This patch set fixes theses issues. ==================== Link: https://patch.msgid.link/20250228191935.3953712-1-lee@trager.us Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-04eth: fbnic: Replace firmware field macrosLee Trager
Replace the firmware field macros with new macros which follow typical kernel standards. No variables are required to be predefined for use and results are now returned. These macros are prefixed with fta or fbnic TLV attribute. Signed-off-by: Lee Trager <lee@trager.us> Link: https://patch.msgid.link/20250228191935.3953712-4-lee@trager.us Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-04eth: fbnic: Update fbnic_tlv_attr_get_string() to work like nla_strscpy()Lee Trager
Allow fbnic_tlv_attr_get_string() to return an error code. In the event the source mailbox attribute is missing return -EINVAL. Like nla_strscpy() return -E2BIG when the source string is larger than the destination string. In this case the amount of data copied is equal to dstsize. Signed-off-by: Lee Trager <lee@trager.us> Link: https://patch.msgid.link/20250228191935.3953712-3-lee@trager.us Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-04eth: fbnic: Prepend TSENE FW fields with FBNIC_FWLee Trager
All other firmware fields are prepended with FBNIC_FW. Update TSENE fields to follow the same format. Signed-off-by: Lee Trager <lee@trager.us> Link: https://patch.msgid.link/20250228191935.3953712-2-lee@trager.us Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-04Merge branch ↵Jakub Kicinski
'net-convert-gianfar-triple-speed-ethernet-controller-bindings-to-yaml' J. Neuschäfer says: ==================== net: Convert Gianfar (Triple Speed Ethernet Controller) bindings to YAML The aim of this series is to modernize the device tree bindings for the Freescale "Gianfar" ethernet controller (a.k.a. TSEC, Triple Speed Ethernet Controller) by converting them to YAML. v1: https://lore.kernel.org/20250220-gianfar-yaml-v1-0-0ba97fd1ef92@posteo.net ==================== Link: https://patch.msgid.link/20250228-gianfar-yaml-v2-0-6beeefbd4818@posteo.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-04dt-bindings: net: Convert fsl,gianfar to YAMLJ. Neuschäfer
Add a binding for the "Gianfar" ethernet controller, also known as TSEC/eTSEC. Signed-off-by: J. Neuschäfer <j.ne@posteo.net> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20250228-gianfar-yaml-v2-3-6beeefbd4818@posteo.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-04dt-bindings: net: fsl,gianfar-mdio: Update information about TBIJ. Neuschäfer
When this binding was originally written, all known TSEC Ethernet controllers had a Ten-Bit Interface (TBI). However, some datasheets such as for the MPC8315E suggest that this is not universally true: The eTSECs do not support TBI, GMII, and FIFO operating modes, so all references to these interfaces and features should be ignored for this device. Acked-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: J. Neuschäfer <j.ne@posteo.net> Link: https://patch.msgid.link/20250228-gianfar-yaml-v2-2-6beeefbd4818@posteo.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-04dt-bindings: net: Convert fsl,gianfar-{mdio,tbi} to YAMLJ. Neuschäfer
Move the information related to the Freescale Gianfar (TSEC) MDIO bus and the Ten-Bit Interface (TBI) from fsl-tsec-phy.txt to a new binding file in YAML format, fsl,gianfar-mdio.yaml. Signed-off-by: J. Neuschäfer <j.ne@posteo.net> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20250228-gianfar-yaml-v2-1-6beeefbd4818@posteo.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-04Merge branch 'net-phy-nxp-c45-tja11xx-add-support-for-tja1121'Jakub Kicinski
Andrei Botila says: ==================== net: phy: nxp-c45-tja11xx: add support for TJA1121 This patch series adds .match_phy_device for the existing TJAs to differentiate between TJA1103/TJA1104 and TJA1120/TJA1121. TJA1103 and TJA1104 share the same PHY_ID but TJA1104 has MACsec capabilities while TJA1103 doesn't. Also add support for TJA1121 which is based on TJA1120 hardware with additional MACsec IP. ==================== Link: https://patch.msgid.link/20250228154320.2979000-1-andrei.botila@oss.nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-04net: phy: nxp-c45-tja11xx: add support for TJA1121Andrei Botila
Add support for TJA1121 which is based on TJA1120 but with additional MACsec IP. Signed-off-by: Andrei Botila <andrei.botila@oss.nxp.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250228154320.2979000-3-andrei.botila@oss.nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-04net: phy: nxp-c45-tja11xx: add match_phy_device to TJA1103/TJA1104Andrei Botila
Add .match_phy_device for the existing TJAs to differentiate between TJA1103 and TJA1104. TJA1103 and TJA1104 share the same PHY_ID but TJA1104 has MACsec capabilities while TJA1103 doesn't. Signed-off-by: Andrei Botila <andrei.botila@oss.nxp.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250228154320.2979000-2-andrei.botila@oss.nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-04dpll: Add an assertion to check freq_supported_numJiasheng Jiang
Since the driver is broken in the case that src->freq_supported is not NULL but src->freq_supported_num is 0, add an assertion for it. Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Reviewed-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Link: https://patch.msgid.link/20250228150210.34404-1-jiashengjiangcool@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-04Merge branch 'mptcp-improve-code-coverage-and-small-optimisations'Jakub Kicinski
Matthieu Baerts says: ==================== mptcp: improve code coverage and small optimisations This small series have various unrelated patches: - Patch 1 and 2: improve code coverage by validating mptcp_diag_dump_one thanks to a new tool displaying MPTCP info for a specific token. - Patch 3: a fix for a commit which is only in net-next. - Patch 4: reduce parameters for one in-kernel PM helper. - Patch 5: exit early when processing an ADD_ADDR echo to avoid unneeded operations. ==================== Link: https://patch.msgid.link/20250228-net-next-mptcp-coverage-small-opti-v1-0-f933c4275676@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-04mptcp: pm: exit early with ADD_ADDR echo if possibleMatthieu Baerts (NGI0)
When the userspace PM is used, or when the in-kernel limits are reached, there will be no need to schedule the PM worker to signal new addresses. That corresponds to pm->work_pending set to 0. In this case, an early exit can be done in mptcp_pm_add_addr_echoed() not to hold the PM lock, and iterate over the announced addresses list, not to schedule the worker anyway in this case. This is similar to what is done when a connection or a subflow has been established. Reviewed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250228-net-next-mptcp-coverage-small-opti-v1-5-f933c4275676@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-04mptcp: pm: in-kernel: reduce parameters of set_flagsGeliang Tang
The number of parameters in mptcp_nl_set_flags() can be reduced. Only need to pass a "local" parameter to it instead of "local->addr" and "local->flags". 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/20250228-net-next-mptcp-coverage-small-opti-v1-4-f933c4275676@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-04mptcp: pm: in-kernel: avoid access entry without lockGeliang Tang
In mptcp_pm_nl_set_flags(), "entry" is copied to "local" when pernet->lock is held to avoid direct access to entry without pernet->lock. Therefore, "local->flags" should be passed to mptcp_nl_set_flags instead of "entry->flags" when pernet->lock is not held, so as to avoid access to entry. Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn> Fixes: 145dc6cc4abd ("mptcp: pm: change to fullmesh only for 'subflow'") Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250228-net-next-mptcp-coverage-small-opti-v1-3-f933c4275676@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-04selftests: mptcp: add a test for mptcp_diag_dump_oneGang Yan
This patch introduces a new 'chk_diag' test in diag.sh. It retrieves the token for a specified MPTCP socket (msk) using the 'ss' command and then accesses the 'mptcp_diag_dump_one' in kernel via ./mptcp_diag to verify if the correct token is returned. Link: https://github.com/multipath-tcp/mptcp_net-next/issues/524 Signed-off-by: Gang Yan <yangang@kylinos.cn> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250228-net-next-mptcp-coverage-small-opti-v1-2-f933c4275676@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-04selftests: mptcp: Add a tool to get specific msk_infoGang Yan
This patch enables the retrieval of the mptcp_info structure corresponding to a specified MPTCP socket (msk). When multiple MPTCP connections are present, specific information can be obtained for a given connection through the 'mptcp_diag_dump_one' by using the 'token' associated with the msk. Signed-off-by: Gang Yan <yangang@kylinos.cn> Co-developed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250228-net-next-mptcp-coverage-small-opti-v1-1-f933c4275676@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-04ppp: Fix KMSAN uninit-value warning with bpfJiayuan Chen
Syzbot caught an "KMSAN: uninit-value" warning [1], which is caused by the ppp driver not initializing a 2-byte header when using socket filter. The following code can generate a PPP filter BPF program: ''' struct bpf_program fp; pcap_t *handle; handle = pcap_open_dead(DLT_PPP_PPPD, 65535); pcap_compile(handle, &fp, "ip and outbound", 0, 0); bpf_dump(&fp, 1); ''' Its output is: ''' (000) ldh [2] (001) jeq #0x21 jt 2 jf 5 (002) ldb [0] (003) jeq #0x1 jt 4 jf 5 (004) ret #65535 (005) ret #0 ''' Wen can find similar code at the following link: https://github.com/ppp-project/ppp/blob/master/pppd/options.c#L1680 The maintainer of this code repository is also the original maintainer of the ppp driver. As you can see the BPF program skips 2 bytes of data and then reads the 'Protocol' field to determine if it's an IP packet. Then it read the first byte of the first 2 bytes to determine the direction. The issue is that only the first byte indicating direction is initialized in current ppp driver code while the second byte is not initialized. For normal BPF programs generated by libpcap, uninitialized data won't be used, so it's not a problem. However, for carefully crafted BPF programs, such as those generated by syzkaller [2], which start reading from offset 0, the uninitialized data will be used and caught by KMSAN. [1] https://syzkaller.appspot.com/bug?extid=853242d9c9917165d791 [2] https://syzkaller.appspot.com/text?tag=ReproC&x=11994913980000 Cc: Paul Mackerras <paulus@samba.org> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+853242d9c9917165d791@syzkaller.appspotmail.com Closes: https://lore.kernel.org/bpf/000000000000dea025060d6bc3bc@google.com/ Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250228141408.393864-1-jiayuan.chen@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-04Merge branch 'fixes-for-ipa-v4-7'Jakub Kicinski
Luca Weiss says: ==================== Fixes for IPA v4.7 During bringup of IPA v4.7 unfortunately some bits were missed, and it couldn't be tested much back then due to missing features in tqftpserv which caused the modem to not enable correctly. Especially the last commit is important since it makes mobile data actually functional on SoCs with IPA v4.7 like SM6350 - used on the Fairphone 4. Before that, you'd get an IP address on the interface but then e.g. ping never got any response back. ==================== Link: https://patch.msgid.link/20250227-ipa-v4-7-fixes-v1-0-a88dd8249d8a@fairphone.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-04net: ipa: Enable checksum for IPA_ENDPOINT_AP_MODEM_{RX,TX} for v4.7Luca Weiss
Enable the checksum option for these two endpoints in order to allow mobile data to actually work. Without this, no packets seem to make it through the IPA. Fixes: b310de784bac ("net: ipa: add IPA v4.7 support") Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Reviewed-by: Alex Elder <elder@riscstar.com> Link: https://patch.msgid.link/20250227-ipa-v4-7-fixes-v1-3-a88dd8249d8a@fairphone.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-04net: ipa: Fix QSB data for v4.7Luca Weiss
As per downstream reference, max_writes should be 12 and max_reads should be 13. Fixes: b310de784bac ("net: ipa: add IPA v4.7 support") Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Reviewed-by: Alex Elder <elder@riscstar.com> Link: https://patch.msgid.link/20250227-ipa-v4-7-fixes-v1-2-a88dd8249d8a@fairphone.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-04net: ipa: Fix v4.7 resource group namesLuca Weiss
In the downstream IPA driver there's only one group defined for source and destination, and the destination group doesn't have a _DPL suffix. Fixes: b310de784bac ("net: ipa: add IPA v4.7 support") Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Reviewed-by: Alex Elder <elder@riscstar.com> Link: https://patch.msgid.link/20250227-ipa-v4-7-fixes-v1-1-a88dd8249d8a@fairphone.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-04HID: Intel-thc-hid: Intel-quickspi: Correct device state after S4Even Xu
During S4 retore flow, quickspi device was resetted by driver and state was changed to RESETTED. It is needed to be change to ENABLED state after S4 re-initialization finished, otherwise, device will run in wrong state and HID input data will be dropped. Signed-off-by: Even Xu <even.xu@intel.com> Fixes: 6912aaf3fd24 ("HID: intel-thc-hid: intel-quickspi: Add PM implementation") Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-03-04HID: intel-thc-hid: Fix spelling mistake "intput" -> "input"Colin Ian King
There is a spelling mistake in a dev_err_once message. Fix it. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Reviewed-by: Even Xu <even.xu@intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-03-04HID: hid-steam: Fix use-after-free when detaching deviceVicki Pfau
When a hid-steam device is removed it must clean up the client_hdev used for intercepting hidraw access. This can lead to scheduling deferred work to reattach the input device. Though the cleanup cancels the deferred work, this was done before the client_hdev itself is cleaned up, so it gets rescheduled. This patch fixes the ordering to make sure the deferred work is properly canceled. Reported-by: syzbot+0154da2d403396b2bd59@syzkaller.appspotmail.com Fixes: 79504249d7e2 ("HID: hid-steam: Move hidraw input (un)registering to work") Signed-off-by: Vicki Pfau <vi@endrift.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-03-04HID: debug: Fix spelling mistake "Messanger" -> "Messenger"Colin Ian King
There is a spelling mistake in a literal string. Fix it. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-03-04HID: appleir: Fix potential NULL dereference at raw event handleDaniil Dulov
Syzkaller reports a NULL pointer dereference issue in input_event(). BUG: KASAN: null-ptr-deref in instrument_atomic_read include/linux/instrumented.h:68 [inline] BUG: KASAN: null-ptr-deref in _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] BUG: KASAN: null-ptr-deref in is_event_supported drivers/input/input.c:67 [inline] BUG: KASAN: null-ptr-deref in input_event+0x42/0xa0 drivers/input/input.c:395 Read of size 8 at addr 0000000000000028 by task syz-executor199/2949 CPU: 0 UID: 0 PID: 2949 Comm: syz-executor199 Not tainted 6.13.0-rc4-syzkaller-00076-gf097a36ef88d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 kasan_report+0xd9/0x110 mm/kasan/report.c:602 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189 instrument_atomic_read include/linux/instrumented.h:68 [inline] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] is_event_supported drivers/input/input.c:67 [inline] input_event+0x42/0xa0 drivers/input/input.c:395 input_report_key include/linux/input.h:439 [inline] key_down drivers/hid/hid-appleir.c:159 [inline] appleir_raw_event+0x3e5/0x5e0 drivers/hid/hid-appleir.c:232 __hid_input_report.constprop.0+0x312/0x440 drivers/hid/hid-core.c:2111 hid_ctrl+0x49f/0x550 drivers/hid/usbhid/hid-core.c:484 __usb_hcd_giveback_urb+0x389/0x6e0 drivers/usb/core/hcd.c:1650 usb_hcd_giveback_urb+0x396/0x450 drivers/usb/core/hcd.c:1734 dummy_timer+0x17f7/0x3960 drivers/usb/gadget/udc/dummy_hcd.c:1993 __run_hrtimer kernel/time/hrtimer.c:1739 [inline] __hrtimer_run_queues+0x20a/0xae0 kernel/time/hrtimer.c:1803 hrtimer_run_softirq+0x17d/0x350 kernel/time/hrtimer.c:1820 handle_softirqs+0x206/0x8d0 kernel/softirq.c:561 __do_softirq kernel/softirq.c:595 [inline] invoke_softirq kernel/softirq.c:435 [inline] __irq_exit_rcu+0xfa/0x160 kernel/softirq.c:662 irq_exit_rcu+0x9/0x30 kernel/softirq.c:678 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvec_apic_timer_interrupt+0x90/0xb0 arch/x86/kernel/apic/apic.c:1049 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702 __mod_timer+0x8f6/0xdc0 kernel/time/timer.c:1185 add_timer+0x62/0x90 kernel/time/timer.c:1295 schedule_timeout+0x11f/0x280 kernel/time/sleep_timeout.c:98 usbhid_wait_io+0x1c7/0x380 drivers/hid/usbhid/hid-core.c:645 usbhid_init_reports+0x19f/0x390 drivers/hid/usbhid/hid-core.c:784 hiddev_ioctl+0x1133/0x15b0 drivers/hid/usbhid/hiddev.c:794 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+0x190/0x200 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> This happens due to the malformed report items sent by the emulated device which results in a report, that has no fields, being added to the report list. Due to this appleir_input_configured() is never called, hidinput_connect() fails which results in the HID_CLAIMED_INPUT flag is not being set. However, it does not make appleir_probe() fail and lets the event callback to be called without the associated input device. Thus, add a check for the HID_CLAIMED_INPUT flag and leave the event hook early if the driver didn't claim any input_dev for some reason. Moreover, some other hid drivers accessing input_dev in their event callbacks do have similar checks, too. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 9a4a5574ce42 ("HID: appleir: add support for Apple ir devices") Cc: stable@vger.kernel.org Signed-off-by: Daniil Dulov <d.dulov@aladdin.ru> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-03-04HID: apple: disable Fn key handling on the Omoton KB066Alex Henrie
Remove the fixup to make the Omoton KB066's F6 key F6 when not holding Fn. That was really just a hack to allow typing F6 in fnmode>0, and it didn't fix any of the other F keys that were likewise untypable in fnmode>0. Instead, because the Omoton's Fn key is entirely internal to the keyboard, completely disable Fn key translation when an Omoton is detected, which will prevent the hid-apple driver from interfering with the keyboard's built-in Fn key handling. All of the F keys, including F6, are then typable when Fn is held. The Omoton KB066 and the Apple A1255 both have HID product code 05ac:022c. The self-reported name of every original A1255 when they left the factory was "Apple Wireless Keyboard". By default, Mac OS changes the name to "<username>'s keyboard" when pairing with the keyboard, but Mac OS allows the user to set the internal name of Apple keyboards to anything they like. The Omoton KB066's name, on the other hand, is not configurable: It is always "Bluetooth Keyboard". Because that name is so generic that a user might conceivably use the same name for a real Apple keyboard, detect Omoton keyboards based on both having that exact name and having HID product code 022c. Fixes: 819083cb6eed ("HID: apple: fix up the F6 key on the Omoton KB066 keyboard") Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> Reviewed-by: Aditya Garg <gargaditya08@live.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-03-04HID: i2c-hid: improve i2c_hid_get_report error messageWentao Guan
We have two places to print "failed to set a report to ...", use "get a report from" instead of "set a report to", it makes people who knows less about the module to know where the error happened. Before: i2c_hid_acpi i2c-FTSC1000:00: failed to set a report to device: -11 After: i2c_hid_acpi i2c-FTSC1000:00: failed to get a report from device: -11 Signed-off-by: Wentao Guan <guanwentao@uniontech.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-03-04Merge tag 'devicetree-fixes-for-6.14-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux Pull devicetree fix from Rob Herring: - Revert reserved-memory 'alignment' property to use '#address-cells' instead of '#size-cells'. What's in use trumps the spec. * tag 'devicetree-fixes-for-6.14-2' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: Revert "of: reserved-memory: Fix using wrong number of cells to get property 'alignment'"
2025-03-04fs/pipe: Read pipe->{head,tail} atomically outside pipe->mutexLinus Torvalds
pipe_readable(), pipe_writable(), and pipe_poll() can read "pipe->head" and "pipe->tail" outside of "pipe->mutex" critical section. When the head and the tail are read individually in that order, there is a window for interruption between the two reads in which both the head and the tail can be updated by concurrent readers and writers. One of the problematic scenarios observed with hackbench running multiple groups on a large server on a particular pipe inode is as follows: pipe->head = 36 pipe->tail = 36 hackbench-118762 [057] ..... 1029.550548: pipe_write: *wakes up: pipe not full* hackbench-118762 [057] ..... 1029.550548: pipe_write: head: 36 -> 37 [tail: 36] hackbench-118762 [057] ..... 1029.550548: pipe_write: *wake up next reader 118740* hackbench-118762 [057] ..... 1029.550548: pipe_write: *wake up next writer 118768* hackbench-118768 [206] ..... 1029.55055X: pipe_write: *writer wakes up* hackbench-118768 [206] ..... 1029.55055X: pipe_write: head = READ_ONCE(pipe->head) [37] ... CPU 206 interrupted (exact wakeup was not traced but 118768 did read head at 37 in traces) hackbench-118740 [057] ..... 1029.550558: pipe_read: *reader wakes up: pipe is not empty* hackbench-118740 [057] ..... 1029.550558: pipe_read: tail: 36 -> 37 [head = 37] hackbench-118740 [057] ..... 1029.550559: pipe_read: *pipe is empty; wakeup writer 118768* hackbench-118740 [057] ..... 1029.550559: pipe_read: *sleeps* hackbench-118766 [185] ..... 1029.550592: pipe_write: *New writer comes in* hackbench-118766 [185] ..... 1029.550592: pipe_write: head: 37 -> 38 [tail: 37] hackbench-118766 [185] ..... 1029.550592: pipe_write: *wakes up reader 118766* hackbench-118740 [185] ..... 1029.550598: pipe_read: *reader wakes up; pipe not empty* hackbench-118740 [185] ..... 1029.550599: pipe_read: tail: 37 -> 38 [head: 38] hackbench-118740 [185] ..... 1029.550599: pipe_read: *pipe is empty* hackbench-118740 [185] ..... 1029.550599: pipe_read: *reader sleeps; wakeup writer 118768* ... CPU 206 switches back to writer hackbench-118768 [206] ..... 1029.550601: pipe_write: tail = READ_ONCE(pipe->tail) [38] hackbench-118768 [206] ..... 1029.550601: pipe_write: pipe_full()? (u32)(37 - 38) >= 16? Yes hackbench-118768 [206] ..... 1029.550601: pipe_write: *writer goes back to sleep* [ Tasks 118740 and 118768 can then indefinitely wait on each other. ] The unsigned arithmetic in pipe_occupancy() wraps around when "pipe->tail > pipe->head" leading to pipe_full() returning true despite the pipe being empty. The case of genuine wraparound of "pipe->head" is handled since pipe buffer has data allowing readers to make progress until the pipe->tail wraps too after which the reader will wakeup a sleeping writer, however, mistaking the pipe to be full when it is in fact empty can lead to readers and writers waiting on each other indefinitely. This issue became more problematic and surfaced as a hang in hackbench after the optimization in commit aaec5a95d596 ("pipe_read: don't wake up the writer if the pipe is still full") significantly reduced the number of spurious wakeups of writers that had previously helped mask the issue. To avoid missing any updates between the reads of "pipe->head" and "pipe->write", unionize the two with a single unsigned long "pipe->head_tail" member that can be loaded atomically. Using "pipe->head_tail" to read the head and the tail ensures the lockless checks do not miss any updates to the head or the tail and since those two are only updated under "pipe->mutex", it ensures that the head is always ahead of, or equal to the tail resulting in correct calculations. [ prateek: commit log, testing on x86 platforms. ] Reported-and-debugged-by: Swapnil Sapkal <swapnil.sapkal@amd.com> Closes: https://lore.kernel.org/lkml/e813814e-7094-4673-bc69-731af065a0eb@amd.com/ Reported-by: Alexey Gladkov <legion@kernel.org> Closes: https://lore.kernel.org/all/Z8Wn0nTvevLRG_4m@example.org/ Fixes: 8cefc107ca54 ("pipe: Use head and tail pointers for the ring, not cursor and length") Tested-by: Swapnil Sapkal <swapnil.sapkal@amd.com> Reviewed-by: Oleg Nesterov <oleg@redhat.com> Tested-by: Alexey Gladkov <legion@kernel.org> Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2025-03-04Merge tag 'wireless-next-2025-03-04-v2' of ↵Jakub Kicinski
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Johannes Berg says: ==================== First 6.15 material: * cfg80211/mac80211 - remove cooked monitor support - strict mode for better AP testing - basic EPCS support - OMI RX bandwidth reduction support * rtw88 - preparation for RTL8814AU support * rtw89 - use wiphy_lock/wiphy_work - preparations for MLO - BT-Coex improvements - regulatory support in firmware files * iwlwifi - preparations for the new iwlmld sub-driver * tag 'wireless-next-2025-03-04-v2' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (128 commits) wifi: iwlwifi: remove mld/roc.c wifi: mac80211: refactor populating mesh related fields in sinfo wifi: cfg80211: reorg sinfo structure elements for mesh wifi: iwlwifi: Fix spelling mistake "Increate" -> "Increase" wifi: iwlwifi: add Debug Host Command APIs wifi: iwlwifi: add IWL_MAX_NUM_IGTKS macro wifi: iwlwifi: add OMI bandwidth reduction APIs wifi: iwlwifi: remove mvm prefix from iwl_mvm_d3_end_notif wifi: iwlwifi: remember if the UATS table was read successfully wifi: iwlwifi: export iwl_get_lari_config_bitmap wifi: iwlwifi: add support for external 32 KHz clock wifi: iwlwifi: mld: add a debug level for EHT prints wifi: iwlwifi: mld: add a debug level for PTP prints wifi: iwlwifi: remove mvm prefix from iwl_mvm_esr_mode_notif wifi: iwlwifi: use 0xff instead of 0xffffffff for invalid wifi: iwlwifi: location api cleanup wifi: cfg80211: expose update timestamp to drivers wifi: mac80211: add ieee80211_iter_chan_contexts_mtx wifi: mac80211: fix integer overflow in hwmp_route_info_get() wifi: mac80211: Fix possible integer promotion issue ... ==================== Link: https://patch.msgid.link/20250304125605.127914-3-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-04Merge tag 'wireless-2025-03-04' of ↵Jakub Kicinski
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless Johannes Berg says: ==================== bugfixes for 6.14: * regressions from this cycle: - mac80211: fix sparse warning for monitor - nl80211: disable multi-link reconfiguration (needs fixing) * older issues: - cfg80211: reject badly combined cooked monitor, fix regulatory hint validity checks - mac80211: handle TXQ flush w/o driver per-sta flush, fix debugfs for monitor, fix element inheritance - iwlwifi: fix rfkill, dead firmware handling, rate API version, free A-MSDU handling, avoid large allocations, fix string format - brcmfmac: fix power handling on some boards * tag 'wireless-2025-03-04' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless: wifi: nl80211: disable multi-link reconfiguration wifi: cfg80211: regulatory: improve invalid hints checking wifi: brcmfmac: keep power during suspend if board requires it wifi: mac80211: Fix sparse warning for monitor_sdata wifi: mac80211: fix vendor-specific inheritance wifi: mac80211: fix MLE non-inheritance parsing wifi: iwlwifi: Fix A-MSDU TSO preparation wifi: iwlwifi: Free pages allocated when failing to build A-MSDU wifi: iwlwifi: limit printed string from FW file wifi: iwlwifi: mvm: use the right version of the rate API wifi: iwlwifi: mvm: don't try to talk to a dead firmware wifi: iwlwifi: mvm: don't dump the firmware state upon RFKILL while suspend wifi: iwlwifi: mvm: clean up ROC on failure wifi: iwlwifi: fw: avoid using an uninitialized variable wifi: iwlwifi: fw: allocate chained SG tables for dump wifi: mac80211: remove debugfs dir for virtual monitor wifi: mac80211: Cleanup sta TXQs on flush wifi: nl80211: reject cooked mode if it is set along with other flags ==================== Link: https://patch.msgid.link/20250304124435.126272-3-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-04Merge branch 'netconsole-add-taskname-sysdata-support'Paolo Abeni
Breno Leitao says: ==================== netconsole: Add taskname sysdata support This patchset introduces a new feature to the netconsole extradata subsystem that enables the inclusion of the current task's name in the sysdata output of netconsole messages. This enhancement is particularly valuable for large-scale deployments, such as Meta's, where netconsole collects messages from millions of servers and stores them in a data warehouse for analysis. Engineers often rely on these messages to investigate issues and assess kernel health. One common challenge we face is determining the context in which a particular message was generated. By including the task name (task->comm) with each message, this feature provides a direct answer to the frequently asked question: "What was running when this message was generated?" This added context will significantly improve our ability to diagnose and troubleshoot issues, making it easier to interpret output of netconsole. The patchset consists of seven patches that implement the following changes: * Refactor CPU number formatting into a separate function * Prefix CPU_NR sysdata feature with SYSDATA_ * Patch to covert a bitwise operation into boolean * Add configfs controls for taskname sysdata feature * Add taskname to extradata entry count * Add support for including task name in netconsole's extra data output * Document the task name feature in Documentation/networking/netconsole.rst * Add test coverage for the task name feature to the existing sysdata selftest script These changes allow users to enable or disable the task name feature via configfs and provide additional context for kernel messages by showing which task generated each console message. I have tested these patches on some servers and they seem to work as expected. v1: https://lore.kernel.org/r/20250221-netcons_current-v1-0-21c86ae8fc0d@debian.org Signed-off-by: Breno Leitao <leitao@debian.org> ==================== Link: https://patch.msgid.link/20250228-netcons_current-v2-0-f53ff79a0db2@debian.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-04netconsole: selftest: add task name append testingBreno Leitao
Add test coverage for the netconsole task name feature to the existing sysdata selftest script. This extends the test infrastructure to verify that task names are correctly appended when enabled and absent when disabled. The test validates that: - Task names appear in the expected format "taskname=<name>" - Task names are included when the feature is enabled - Task names are excluded when the feature is disabled - The feature works correctly alongside other sysdata fields like CPU Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-04netconsole: docs: document the task name featureBreno Leitao
Add documentation for the netconsole task name feature in Documentation/networking/netconsole.rst. This explains how to enable task name via configfs and demonstrates the output format. The documentation includes: - How to enable/disable the feature via taskname_enabled - The format of the task name in the output - An example showing the task name appearing in messages Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-04netconsole: add task name to extra data fieldsBreno Leitao
This is the core patch for this whole patchset. Add support for including the current task's name in netconsole's extra data output. This adds a new append_taskname() function that writes the task name (from current->comm) into the target's extradata buffer, similar to how CPU numbers are handled. The task name is included when the SYSDATA_TASKNAME field is set, appearing in the format "taskname=<name>" in the output. This additional context can help with debugging by showing which task generated each console message. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-04netconsole: add configfs controls for taskname sysdata featureBreno Leitao
Add configfs interface to enable/disable the taskname sysdata feature. This adds the following functionality: The implementation follows the same pattern as the existing CPU number feature, ensuring consistent behavior and error handling across sysdata features. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-04netconsole: add taskname to extradata entry countBreno Leitao
New SYSDATA_TASKNAME feature flag to track when taskname append is enabled. Additional check in count_extradata_entries() to include taskname in total, counting it as an entry in extradata. This function is used to check if we are not overflowing the number of extradata items. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-04netconsole: refactor CPU number formatting into separate functionBreno Leitao
Extract CPU number formatting logic from prepare_extradata() into a new append_cpu_nr() function. This refactoring improves code organization by isolating CPU number formatting into its own function while reducing the complexity of prepare_extradata(). The change prepares the codebase for the upcoming taskname feature by establishing a consistent pattern for handling sysdata features. The CPU number formatting logic itself remains unchanged; only its location has moved to improve maintainability. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-04netconsole: Make boolean comparison consistentBreno Leitao
Convert the current state assignment to use explicit boolean conversion, making the code more robust and easier to read. This change adds a double-negation operator to ensure consistent boolean conversion as suggested by Paolo[1]. This approach aligns with the existing pattern used in sysdata_cpu_nr_enabled_show(). Link: https://lore.kernel.org/all/7309e760-63b0-4b58-ad33-2fb8db361141@redhat.com/ [1] Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-04netconsole: prefix CPU_NR sysdata feature with SYSDATA_Breno Leitao
Rename the CPU_NR enum value to SYSDATA_CPU_NR to establish a consistent naming convention for sysdata features. This change prepares for upcoming additions to the sysdata feature set by clearly grouping related features under the SYSDATA prefix. This change is purely cosmetic and does not modify any functionality. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-04wifi: iwlwifi: remove mld/roc.cJohannes Berg
This file should never have been part of the commit, remove it. Fixes: af3be9088404 ("wifi: iwlwifi: support ROC version 6") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-03-04Merge branch 'support-some-enhances-features-for-the-hibmcge-driver'Paolo Abeni
Jijie Shao says: ==================== Support some enhances features for the HIBMCGE driver In this patch set, we mainly implement some enhanced features. It mainly includes the statistics, diagnosis, and ioctl to improve fault locating efficiency, abnormal irq and MAC link exception handling feature to enhance driver robustness, and rx checksum offload feature to improve performance (tx checksum feature has been implemented). v3: https://lore.kernel.org/all/20250221115526.1082660-2-shaojijie@huawei.com/ v2: https://lore.kernel.org/all/20250218085829.3172126-1-shaojijie@huawei.com/ v1: https://lore.kernel.org/all/20250213035529.2402283-1-shaojijie@huawei.com/ ==================== Link: https://patch.msgid.link/20250228115411.1750803-1-shaojijie@huawei.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-04net: hibmcge: Add support for ioctlJijie Shao
This patch implements the .ndo_eth_ioctl() to read and write the PHY register. Signed-off-by: Jijie Shao <shaojijie@huawei.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-04net: hibmcge: Add support for BMC diagnose featureJijie Shao
The MAC hardware is on the BMC side, and the driver is on the host side. When the driver is abnormal, the BMC cannot directly detect the exception cause. Therefore, this patch implements the BMC diagnosis feature. When users query driver diagnosis information on the BMC, the driver detects the query request in the scheduled task and reports driver statistics and link status to the BMC through the bar space. The BMC collects logs to analyze exception causes. Currently, the scheduled task is executed every 30 seconds To quickly respond to user query requests, this patch changes the scheduled task to once every second. Signed-off-by: Jijie Shao <shaojijie@huawei.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-04net: hibmcge: Add support for mac link exception handling featureJijie Shao
If the rate changed frequently, the PHY link ok, but the MAC link maybe fails. As a result, the network port is unavailable. According to the documents of the chip, core_reset needs to do to fix the fault. In hw_adjus_link(), the core_reset is added to try to ensure that MAC link status is normal. In addition, MAC link failure detection is added. If the MAC link fails after core_reset, driver invokes the phy_stop() and phy_start() to re-link. Due to phydev->lock, re-link cannot be triggered in adjust_link(). Therefore, this operation is invoked in a scheduled task. Signed-off-by: Jijie Shao <shaojijie@huawei.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>