summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-07-15net: mctp: Add bind lookup testMatt Johnston
Test the preference order of bound socket matches with a series of test packets. Signed-off-by: Matt Johnston <matt@codeconstruct.com.au> Link: https://patch.msgid.link/20250710-mctp-bind-v4-8-8ec2f6460c56@codeconstruct.com.au Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-07-15net: mctp: Test conflicts of connect() with bind()Matt Johnston
The addition of connect() adds new conflict cases to test. Signed-off-by: Matt Johnston <matt@codeconstruct.com.au> Link: https://patch.msgid.link/20250710-mctp-bind-v4-7-8ec2f6460c56@codeconstruct.com.au Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-07-15net: mctp: Allow limiting binds to a peer addressMatt Johnston
Prior to calling bind() a program may call connect() on a socket to restrict to a remote peer address. Using connect() is the normal mechanism to specify a remote network peer, so we use that here. In MCTP connect() is only used for bound sockets - send() is not available for MCTP since a tag must be provided for each message. The smctp_type must match between connect() and bind() calls. Signed-off-by: Matt Johnston <matt@codeconstruct.com.au> Link: https://patch.msgid.link/20250710-mctp-bind-v4-6-8ec2f6460c56@codeconstruct.com.au Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-07-15net: mctp: Use hashtable for bindsMatt Johnston
Ensure that a specific EID (remote or local) bind will match in preference to a MCTP_ADDR_ANY bind. This adds infrastructure for binding a socket to receive messages from a specific remote peer address, a future commit will expose an API for this. Signed-off-by: Matt Johnston <matt@codeconstruct.com.au> Link: https://patch.msgid.link/20250710-mctp-bind-v4-5-8ec2f6460c56@codeconstruct.com.au Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-07-15net: mctp: Add test for conflicting bind()sMatt Johnston
Test pairwise combinations of bind addresses and types. Signed-off-by: Matt Johnston <matt@codeconstruct.com.au> Link: https://patch.msgid.link/20250710-mctp-bind-v4-4-8ec2f6460c56@codeconstruct.com.au Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-07-15net: mctp: Treat MCTP_NET_ANY specially in bind()Matt Johnston
When a specific EID is passed as a bind address, it only makes sense to interpret with an actual network ID, so resolve that to the default network at bind time. For bind address of MCTP_ADDR_ANY, we want to be able to capture traffic to any network and address, so keep the current behaviour of matching traffic from any network interface (don't interpret MCTP_NET_ANY as the default network ID). Signed-off-by: Matt Johnston <matt@codeconstruct.com.au> Link: https://patch.msgid.link/20250710-mctp-bind-v4-3-8ec2f6460c56@codeconstruct.com.au Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-07-15net: mctp: Prevent duplicate bindsMatt Johnston
Disallow bind() calls that have the same arguments as existing bound sockets. Previously multiple sockets could bind() to the same type/local address, with an arbitrary socket receiving matched messages. This is only a partial fix, a future commit will define precedence order for MCTP_ADDR_ANY versus specific EID bind(), which are allowed to exist together. Signed-off-by: Matt Johnston <matt@codeconstruct.com.au> Link: https://patch.msgid.link/20250710-mctp-bind-v4-2-8ec2f6460c56@codeconstruct.com.au Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-07-15net: mctp: mctp_test_route_extaddr_input cleanupMatt Johnston
The sock was not being released. Other than leaking, the stale socket will conflict with subsequent bind() calls in unrelated MCTP tests. Fixes: 46ee16462fed ("net: mctp: test: Add extaddr routing output test") Signed-off-by: Matt Johnston <matt@codeconstruct.com.au> Link: https://patch.msgid.link/20250710-mctp-bind-v4-1-8ec2f6460c56@codeconstruct.com.au Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-07-15can: tcan4x5x: fix reset gpio usage during probeBrett Werling
Fixes reset GPIO usage during probe by ensuring we retrieve the GPIO and take the device out of reset (if it defaults to being in reset) before we attempt to communicate with the device. This is achieved by moving the call to tcan4x5x_get_gpios() before tcan4x5x_find_version() and avoiding any device communication while getting the GPIOs. Once we determine the version, we can then take the knowledge of which GPIOs we obtained and use it to decide whether we need to disable the wake or state pin functions within the device. This change is necessary in a situation where the reset GPIO is pulled high externally before the CPU takes control of it, meaning we need to explicitly bring the device out of reset before we can start communicating with it at all. This also has the effect of fixing an issue where a reset of the device would occur after having called tcan4x5x_disable_wake(), making the original behavior not actually disable the wake. This patch should now disable wake or state pin functions well after the reset occurs. Signed-off-by: Brett Werling <brett.werling@garmin.com> Link: https://patch.msgid.link/20250711141728.1826073-1-brett.werling@garmin.com Cc: Markus Schneider-Pargmann <msp@baylibre.com> Fixes: 142c6dc6d9d7 ("can: tcan4x5x: Add support for tcan4552/4553") Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-07-15wifi: iwlwifi: Fix botched indexing conversionVille Syrjälä
The conversion from compiler assisted indexing to manual indexing wasn't done correctly. The array is still made up of __le16 elements so multiplying the outer index by the element size is not what we want. Fix it up. This causes the kernel to oops when trying to transfer any significant amount of data over wifi: BUG: unable to handle page fault for address: ffffc900009f5282 PGD 100000067 P4D 100000067 PUD 1000fb067 PMD 102e82067 PTE 0 Oops: Oops: 0002 [#1] SMP CPU: 1 UID: 0 PID: 99 Comm: kworker/u8:3 Not tainted 6.15.0-rc2-cl-bisect3-00604-g6204d5130a64-dirty #78 PREEMPT Hardware name: Dell Inc. Latitude E5400 /0D695C, BIOS A19 06/13/2013 Workqueue: events_unbound cfg80211_wiphy_work [cfg80211] RIP: 0010:iwl_trans_pcie_tx+0x4dd/0xe60 [iwlwifi] Code: 00 00 66 81 fa ff 0f 0f 87 42 09 00 00 3d ff 00 00 00 0f 8f 37 09 00 00 41 c1 e0 0c 41 09 d0 48 8d 14 b6 48 c1 e2 07 48 01 ca <66> 44 89 04 57 48 8d 0c 12 83 f8 3f 0f 8e 84 01 00 00 41 8b 85 80 RSP: 0018:ffffc900001c3b50 EFLAGS: 00010206 RAX: 00000000000000c1 RBX: ffff88810b180028 RCX: 00000000000000c1 RDX: 0000000000002141 RSI: 000000000000000d RDI: ffffc900009f1000 RBP: 0000000000000002 R08: 0000000000000025 R09: ffffffffa050fa60 R10: 00000000fbdbf4bc R11: 0000000000000082 R12: ffff88810e5ade40 R13: ffff88810af81588 R14: 000000000000001a R15: ffff888100dfe0c8 FS: 0000000000000000(0000) GS:ffff8881998c3000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc900009f5282 CR3: 0000000001e39000 CR4: 00000000000426f0 Call Trace: <TASK> ? rcu_is_watching+0xd/0x40 ? __iwl_dbg+0xb1/0xe0 [iwlwifi] iwlagn_tx_skb+0x8e2/0xcb0 [iwldvm] iwlagn_mac_tx+0x18/0x30 [iwldvm] ieee80211_handle_wake_tx_queue+0x6c/0xc0 [mac80211] ieee80211_agg_start_txq+0x140/0x2e0 [mac80211] ieee80211_agg_tx_operational+0x126/0x210 [mac80211] ieee80211_process_addba_resp+0x27b/0x2a0 [mac80211] ieee80211_iface_work+0x4bd/0x4d0 [mac80211] ? _raw_spin_unlock_irq+0x1f/0x40 cfg80211_wiphy_work+0x117/0x1f0 [cfg80211] process_one_work+0x1ee/0x570 worker_thread+0x1c5/0x3b0 ? bh_worker+0x240/0x240 kthread+0x110/0x220 ? kthread_queue_delayed_work+0x90/0x90 ret_from_fork+0x28/0x40 ? kthread_queue_delayed_work+0x90/0x90 ret_from_fork_asm+0x11/0x20 </TASK> Modules linked in: ctr aes_generic ccm sch_fq_codel bnep xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables btusb btrtl btintel btbcm bluetooth ecdh_generic ecc libaes hid_generic usbhid hid binfmt_misc joydev mousedev snd_hda_codec_hdmi iwldvm snd_hda_codec_idt snd_hda_codec_generic mac80211 coretemp iTCO_wdt watchdog kvm_intel i2c_dev snd_hda_intel libarc4 kvm snd_intel_dspcfg sdhci_pci sdhci_uhs2 snd_hda_codec iwlwifi sdhci irqbypass cqhci snd_hwdep snd_hda_core cfg80211 firewire_ohci mmc_core psmouse snd_pcm i2c_i801 firewire_core pcspkr led_class uhci_hcd i2c_smbus tg3 crc_itu_t iosf_mbi snd_timer rfkill libphy ehci_pci snd ehci_hcd lpc_ich mfd_core usbcore video intel_agp usb_common soundcore intel_gtt evdev agpgart parport_pc wmi parport backlight CR2: ffffc900009f5282 ---[ end trace 0000000000000000 ]--- RIP: 0010:iwl_trans_pcie_tx+0x4dd/0xe60 [iwlwifi] Code: 00 00 66 81 fa ff 0f 0f 87 42 09 00 00 3d ff 00 00 00 0f 8f 37 09 00 00 41 c1 e0 0c 41 09 d0 48 8d 14 b6 48 c1 e2 07 48 01 ca <66> 44 89 04 57 48 8d 0c 12 83 f8 3f 0f 8e 84 01 00 00 41 8b 85 80 RSP: 0018:ffffc900001c3b50 EFLAGS: 00010206 RAX: 00000000000000c1 RBX: ffff88810b180028 RCX: 00000000000000c1 RDX: 0000000000002141 RSI: 000000000000000d RDI: ffffc900009f1000 RBP: 0000000000000002 R08: 0000000000000025 R09: ffffffffa050fa60 R10: 00000000fbdbf4bc R11: 0000000000000082 R12: ffff88810e5ade40 R13: ffff88810af81588 R14: 000000000000001a R15: ffff888100dfe0c8 FS: 0000000000000000(0000) GS:ffff8881998c3000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc900009f5282 CR3: 0000000001e39000 CR4: 00000000000426f0 Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: disabled ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]--- Cc: Miri Korenblit <miriam.rachel.korenblit@intel.com> Fixes: 6204d5130a64 ("wifi: iwlwifi: use bc entries instead of bc table also for pre-ax210") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20250711205744.28723-1-ville.syrjala@linux.intel.com Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2025-07-15wifi: cfg80211: fix double free for link_sinfo in nl80211_station_dump()Sarika Sharma
Currently, the link_sinfo structure is being freed twice in nl80211_dump_station(), once after the send_station() call and again in the error handling path. This results in a double free of both link_sinfo and link_sinfo->pertid, which might lead to undefined behavior or kernel crashes. Hence, fix by ensuring cfg80211_sinfo_release_content() is only invoked once during execution of nl80211_station_dump(). Fixes: 49e47223ecc4 ("wifi: cfg80211: allocate memory for link_station info structure") Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/all/81f30515-a83d-4b05-a9d1-e349969df9e9@sabinyo.mountain/ Reported-by: syzbot+4ba6272678aa468132c8@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/68655325.a70a0220.5d25f.0316.GAE@google.com Signed-off-by: Sarika Sharma <quic_sarishar@quicinc.com> Link: https://patch.msgid.link/20250714084405.178066-1-quic_sarishar@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: cfg80211: fix off channel operation allowed check for MLOAditya Kumar Singh
In cfg80211_off_channel_oper_allowed(), the current logic disallows off-channel operations if any link operates on a radar channel, assuming such channels cannot be vacated. This assumption holds for non-MLO interfaces but not for MLO. With MLO and multi-radio devices, different links may operate on separate radios. This allows one link to scan off-channel while another remains on a radar channel. For example, in a 5 GHz split-phy setup, the lower band can scan while the upper band stays on a radar channel. Off-channel operations can be allowed if the radio/link onto which the input channel falls is different from the radio/link which has an active radar channel. Therefore, fix cfg80211_off_channel_oper_allowed() by returning false only if the requested channel maps to the same radio as an active radar channel. Allow off-channel operations when the requested channel is on a different radio, as in MLO with multi-radio setups. Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Signed-off-by: Amith A <quic_amitajit@quicinc.com> Link: https://patch.msgid.link/20250714040742.538550-1-quic_amitajit@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: mac80211: use RCU-safe iteration in ieee80211_csa_finishMaharaja Kennadyrajan
The ieee80211_csa_finish() function currently uses for_each_sdata_link() to iterate over links of sdata. However, this macro internally uses wiphy_dereference(), which expects the wiphy->mtx lock to be held. When ieee80211_csa_finish() is invoked under an RCU read-side critical section (e.g., under rcu_read_lock()), this leads to a warning from the RCU debugging framework. WARNING: suspicious RCU usage net/mac80211/cfg.c:3830 suspicious rcu_dereference_protected() usage! This warning is triggered because wiphy_dereference() is not safe to use without holding the wiphy mutex, and it is being used in an RCU context without the required locking. Fix this by introducing and using a new macro, for_each_sdata_link_rcu(), which performs RCU-safe iteration over sdata links using list_for_each_entry_rcu() and rcu_dereference(). This ensures that the link pointers are accessed safely under RCU and eliminates the warning. Fixes: f600832794c9 ("wifi: mac80211: restructure tx profile retrieval for MLO MBSSID") Signed-off-by: Maharaja Kennadyrajan <maharaja.kennadyrajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250711033846.40455-1-maharaja.kennadyrajan@oss.qualcomm.com [unindent like the non-RCU macro] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15ipv6: mcast: Avoid a duplicate pointer check in mld_del_delrec()Yue Haibing
Avoid duplicate non-null pointer check for pmc in mld_del_delrec(). No functional changes. Signed-off-by: Yue Haibing <yuehaibing@huawei.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20250714081949.3109947-1-yuehaibing@huawei.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-07-15wifi: mac80211_hwsim: Update comments in headerAlex Gavin
- Reorders 'HWSIM_ATTR_PAD' to after 'HWSIM_ATTR_FREQ', matching order in 'enum hwsim_attrs' - Change references from old commands to new names - Fixes typos Signed-off-by: Alex Gavin <alex.gavin@candelatech.com> Link: https://patch.msgid.link/20250710211437.8516-1-alex.gavin@candelatech.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: mac80211: parse unsolicited broadcast probe response dataYuvarani V
During commands like channel switch and color change, the updated unsolicited broadcast probe response template may be provided. However, this data is not parsed or acted upon in mac80211. Add support to parse it and set the BSS changed flag BSS_CHANGED_UNSOL_BCAST_PROBE_RESP so that drivers could take further action. Signed-off-by: Yuvarani V <quic_yuvarani@quicinc.com> Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Link: https://patch.msgid.link/20250710-update_unsol_bcast_probe_resp-v2-2-31aca39d3b30@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: cfg80211: parse attribute to update unsolicited probe response templateYuvarani V
At present, the updated unsolicited broadcast probe response template is not processed during userspace commands such as channel switch or color change. This leads to an issue where older incorrect unsolicited probe response is still used during these events. Add support to parse the netlink attribute and store it so that mac80211/drivers can use it to set the BSS_CHANGED_UNSOL_BCAST_PROBE_RESP flag in order to send the updated unsolicited broadcast probe response templates during these events. Signed-off-by: Yuvarani V <quic_yuvarani@quicinc.com> Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Link: https://patch.msgid.link/20250710-update_unsol_bcast_probe_resp-v2-1-31aca39d3b30@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: mac80211: don't use TPE data from assoc responseJohannes Berg
Since there's no TPE element in the (re)assoc response, trying to use the data from it just leads to using the defaults, even though the real values had been set during authentication from the discovered BSS information. Fix this by simply not handling the TPE data in assoc response since it's not intended to be present, if it changes later the necessary changes will be made by tracking beacons later. As a side effect, by passing the real frame subtype, now print a correct value for ML reconfiguration responses. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709233537.caa1ca853f5a.I588271f386731978163aa9d84ae75d6f79633e16@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: mac80211: handle WLAN_HT_ACTION_NOTIFY_CHANWIDTH asyncMiri Korenblit
If this action frame, with the value of IEEE80211_HT_CHANWIDTH_ANY, arrives right after a beacon that changed the operational bandwidth from 20 MHz to 40 MHz, then updating the rate control bandwidth to 40 can race with updating the chanctx width (that happens in the beacon proccesing) back to 40 MHz: cpu0 cpu1 ieee80211_rx_mgmt_beacon ieee80211_config_bw ieee80211_link_change_chanreq (*)ieee80211_link_update_chanreq ieee80211_rx_h_action (**)ieee80211_sta_cur_vht_bw (***) ieee80211_recalc_chanctx_chantype in (**), the maximum between the capability width and the bss width is returned. But the bss width was just updated to 40 in (*), so the action frame handling code will increase the width of the rate control before the chanctx was increased (in ***), leading to a FW error (at least in iwlwifi driver. But this is wrong regardless). Fix this by simply handling the action frame async, so it won't race with the beacon proccessing. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218632 Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709233537.bb9dc6f36c35.I39782d6077424e075974c3bee4277761494a1527@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: mac80211: simplify __ieee80211_rx_h_amsdu() loopJohannes Berg
The loop handling individual subframes can be simplified to not use a somewhat confusing goto inside the loop. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709233537.a217a1e8c667.I5283df9627912c06c8327b5786d6b715c6f3a4e1@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: mac80211: don't mark keys for inactive links as uploadedMiri Korenblit
During resume, the driver can call ieee80211_add_gtk_rekey for keys that are not programmed into the device, e.g. keys of inactive links. Don't mark such a key as uploaded to avoid removing it later from the driver/device. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709233537.655094412b0b.Iacae31af3ba2a705da0a9baea976c2f799d65dc4@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: mac80211: only assign chanctx in reconfigMiri Korenblit
At the end of reconfig we are activating all the links that were active before the error. During the activation, _ieee80211_link_use_channel will unassign and re-assign the chanctx from/to the link. But we only need to do the assign, as we are re-building the state as it was before the reconfig. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709233537.6245c3ae7031.Ia5f68992c7c112bea8a426c9339f50c88be3a9ca@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: mac80211_hwsim: Declare support for AP scanningIlan Peer
To support testing scenarios. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709233537.6916e0a49955.I48e374ad7e3ea5877a5e93e5c5fe8301465771c8@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: mac80211: clean up cipher suite handlingJohannes Berg
Under the previous commit's assumption that FIPS isn't supported by hardware, we don't need to modify the cipher suite list, but just need to use the software one instead of the driver's in this case, so clean up the code. Also fix it to exclude TKIP in this case, since that's also dependent on RC4. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709233537.cff427e8f8a5.I744d1ea6a37e3ea55ae8bc3e770acee734eff268@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: mac80211: don't send keys to driver when fips_enabledJohannes Berg
When fips_enabled is set, don't send any keys to the driver (including possibly WoWLAN KEK/KCK material), assuming that no device exists with the necessary certifications. If this turns out to be false in the future, we can add a HW flag. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709233537.e5eebc2b19d8.I968ef8c9ffb48d464ada78685bd25d22349fb063@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: cfg80211: Fix interface type validationIlan Peer
Fix a condition that verified valid values of interface types. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709233537.7ad199ca5939.I0ac1ff74798bf59a87a57f2e18f2153c308b119b@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: mac80211: remove ieee80211_link_unreserve_chanctx() return valueJohannes Berg
All the paths that could return an error are considered misuses of the function and WARN already, and none of the callers ever check the return value. Remove it. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709233537.5b436ee3c20c.Ieff61ec510939adb5fe6da4840557b649b3aa820@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: mac80211: don't unreserve never reserved chanctxJohannes Berg
If a link has no chanctx, indicating it is an inactive link that we tracked CSA for, then attempting to unreserve the reserved chanctx will throw a warning and fail, since there never was a reserved chanctx. Skip the unreserve. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709233537.022192f4b1ae.Ib58156ac13e674a9f4d714735be0764a244c0aae@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15mwl8k: Add missing check after DMA mapThomas Fourier
The DMA map functions can fail and should be tested for errors. If the mapping fails, unmap and return an error. Fixes: 788838ebe8a4 ("mwl8k: use pci_unmap_addr{,set}() to keep track of unmap addresses on rx") Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com> Link: https://patch.msgid.link/20250709111339.25360-2-fourier.thomas@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: mac80211: make VHT opmode NSS ignore a debug messageJohannes Berg
There's no need to always print it, it's only useful for debugging specific client issues. Make it a debug message. Reported-by: Paul Menzel <pmenzel@molgen.mpg.de> Link: https://lore.kernel.org/linux-wireless/20250529070922.3467-1-pmenzel@molgen.mpg.de/ Link: https://patch.msgid.link/20250708105849.22448-2-johannes@sipsolutions.net Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15wifi: cfg80211: remove scan request n_channels counted_byJohannes Berg
This reverts commit e3eac9f32ec0 ("wifi: cfg80211: Annotate struct cfg80211_scan_request with __counted_by"). This really has been a completely failed experiment. There were no actual bugs found, and yet at this point we already have four "fixes" to it, with nothing to show for but code churn, and it never even made the code any safer. In all of the cases that ended up getting "fixed", the structure is also internally inconsistent after the n_channels setting as the channel list isn't actually filled yet. You cannot scan with such a structure, that's just wrong. In mac80211, the struct is also reused multiple times, so initializing it once is no good. Some previous "fixes" (e.g. one in brcm80211) are also just setting n_channels before accessing the array, under the assumption that the code is correct and the array can be accessed, further showing that the whole thing is just pointless when the allocation count and use count are not separate. If we really wanted to fix it, we'd need to separately track the number of channels allocated and the number of channels currently used, but given that no bugs were found despite the numerous syzbot reports, that'd just be a waste of time. Remove the __counted_by() annotation. We really should also remove a number of the n_channels settings that are setting up a structure that's inconsistent, but that can wait. Reported-by: syzbot+e834e757bd9b3d3e1251@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=e834e757bd9b3d3e1251 Fixes: e3eac9f32ec0 ("wifi: cfg80211: Annotate struct cfg80211_scan_request with __counted_by") Link: https://patch.msgid.link/20250714142130.9b0bbb7e1f07.I09112ccde72d445e11348fc2bef68942cb2ffc94@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-15Merge tag 'ath-current-20250714' of ↵Johannes Berg
git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath Jeff Johnson says: ================== ath.git update for v6.16-rc7 Fix an ath12k performance regression introduce in v6.16-rc1 ================== Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-14Merge tag 'for-6.16/dm-fixes-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm Pull device mapper fix from Mikulas Patocka: - dm-bufio: fix scheduling in atomic * tag 'for-6.16/dm-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm: dm-bufio: fix sched in atomic context
2025-07-14Merge branch 'tcp-receiver-changes'Jakub Kicinski
Eric Dumazet says: ==================== tcp: receiver changes Before accepting an incoming packet: - Make sure to not accept a packet beyond advertized RWIN. If not, increment a new SNMP counter (LINUX_MIB_BEYOND_WINDOW) - ooo packets should update rcv_mss and tp->scaling_ratio. - Make sure to not accept packet beyond sk_rcvbuf limit. This series includes three associated packetdrill tests. ==================== Link: https://patch.msgid.link/20250711114006.480026-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-14selftests/net: packetdrill: add tcp_rcv_toobig.pktEric Dumazet
Check that TCP receiver behavior after "tcp: stronger sk_rcvbuf checks" Too fat packet is dropped unless receive queue is empty. Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20250711114006.480026-9-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-14tcp: stronger sk_rcvbuf checksEric Dumazet
Currently, TCP stack accepts incoming packet if sizes of receive queues are below sk->sk_rcvbuf limit. This can cause memory overshoot if the packet is big, like an 1/2 MB BIG TCP one. Refine the check to take into account the incoming skb truesize. Note that we still accept the packet if the receive queue is empty, to not completely freeze TCP flows in pathological conditions. Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20250711114006.480026-8-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-14tcp: add const to tcp_try_rmem_schedule() and sk_rmem_schedule() skbEric Dumazet
These functions to not modify the skb, add a const qualifier. Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20250711114006.480026-7-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-14selftests/net: packetdrill: add tcp_ooo_rcv_mss.pktEric Dumazet
We make sure tcpi_rcv_mss and tp->scaling_ratio are correctly updated if no in-order packet has been received yet. Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20250711114006.480026-6-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-14tcp: call tcp_measure_rcv_mss() for ooo packetsEric Dumazet
tcp_measure_rcv_mss() is used to update icsk->icsk_ack.rcv_mss (tcpi_rcv_mss in tcp_info) and tp->scaling_ratio. Calling it from tcp_data_queue_ofo() makes sure these fields are updated, and permits a better tuning of sk->sk_rcvbuf, in the case a new flow receives many ooo packets. Fixes: dfa2f0483360 ("tcp: get rid of sysctl_tcp_adv_win_scale") Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20250711114006.480026-5-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-14selftests/net: packetdrill: add tcp_rcv_big_endseq.pktEric Dumazet
This test checks TCP behavior when receiving a packet beyond the window. It checks the new TcpExtBeyondWindow SNMP counter. Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20250711114006.480026-4-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-14tcp: add LINUX_MIB_BEYOND_WINDOWEric Dumazet
Add a new SNMP MIB : LINUX_MIB_BEYOND_WINDOW Incremented when an incoming packet is received beyond the receiver window. nstat -az | grep TcpExtBeyondWindow Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20250711114006.480026-3-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-14tcp: do not accept packets beyond windowEric Dumazet
Currently, TCP accepts incoming packets which might go beyond the offered RWIN. Add to tcp_sequence() the validation of packet end sequence. Add the corresponding check in the fast path. We relax this new constraint if the receive queue is empty, to not freeze flows from buggy peers. Add a new drop reason : SKB_DROP_REASON_TCP_INVALID_END_SEQUENCE. Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20250711114006.480026-2-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-14net: wangxun: fix LIBWX dependencies againArnd Bergmann
Two more drivers got added that use LIBWX and cause a build warning WARNING: unmet direct dependencies detected for LIBWX Depends on [m]: NETDEVICES [=y] && ETHERNET [=y] && NET_VENDOR_WANGXUN [=y] && PTP_1588_CLOCK_OPTIONAL [=m] Selected by [y]: - NGBEVF [=y] && NETDEVICES [=y] && ETHERNET [=y] && NET_VENDOR_WANGXUN [=y] && PCI_MSI [=y] Selected by [m]: - NGBE [=m] && NETDEVICES [=y] && ETHERNET [=y] && NET_VENDOR_WANGXUN [=y] && PCI [=y] && PTP_1588_CLOCK_OPTIONAL [=m] ld: drivers/net/ethernet/wangxun/libwx/wx_lib.o: in function `wx_clean_tx_irq': wx_lib.c:(.text+0x5a68): undefined reference to `ptp_schedule_worker' ld: drivers/net/ethernet/wangxun/libwx/wx_ethtool.o: in function `wx_nway_reset': wx_ethtool.c:(.text+0x880): undefined reference to `phylink_ethtool_nway_reset' Add the same dependency on PTP_1588_CLOCK_OPTIONAL to the two driver using this library module, following the pattern from commit 8fa19c2c69fb ("net: wangxun: fix LIBWX dependencies"). Fixes: 377d180bd71c ("net: wangxun: add txgbevf build") Fixes: a0008a3658a3 ("net: wangxun: add ngbevf build") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Simon Horman <horms@kernel.org> # build-tested Link: https://patch.msgid.link/20250711082339.1372821-1-arnd@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-14Add support to set NAPI threaded for individual NAPISamiullah Khawaja
A net device has a threaded sysctl that can be used to enable threaded NAPI polling on all of the NAPI contexts under that device. Allow enabling threaded NAPI polling at individual NAPI level using netlink. Extend the netlink operation `napi-set` and allow setting the threaded attribute of a NAPI. This will enable the threaded polling on a NAPI context. Add a test in `nl_netdev.py` that verifies various cases of threaded NAPI being set at NAPI and at device level. Tested ./tools/testing/selftests/net/nl_netdev.py TAP version 13 1..7 ok 1 nl_netdev.empty_check ok 2 nl_netdev.lo_check ok 3 nl_netdev.page_pool_check ok 4 nl_netdev.napi_list_check ok 5 nl_netdev.dev_set_threaded ok 6 nl_netdev.napi_set_threaded ok 7 nl_netdev.nsim_rxq_reset_down # Totals: pass:7 fail:0 xfail:0 xpass:0 skip:0 error:0 Signed-off-by: Samiullah Khawaja <skhawaja@google.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20250710211203.3979655-1-skhawaja@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-14net: phy: Don't register LEDs for genphySean Anderson
If a PHY has no driver, the genphy driver is probed/removed directly in phy_attach/detach. If the PHY's ofnode has an "leds" subnode, then the LEDs will be (un)registered when probing/removing the genphy driver. This could occur if the leds are for a non-generic driver that isn't loaded for whatever reason. Synchronously removing the PHY device in phy_detach leads to the following deadlock: rtnl_lock() ndo_close() ... phy_detach() phy_remove() phy_leds_unregister() led_classdev_unregister() led_trigger_set() netdev_trigger_deactivate() unregister_netdevice_notifier() rtnl_lock() There is a corresponding deadlock on the open/register side of things (and that one is reported by lockdep), but it requires a race while this one is deterministic. Regular drivers do not have this problem since they are probed asynchronously (without RTNL held). Generic PHYs do not support LEDs anyway, so don't bother registering them. [JakubL this is a net-next version of commit f0f2b992d818 ("net: phy: Don't register LEDs for genphy"), which uses APIs removed in -next.] Signed-off-by: Sean Anderson <sean.anderson@linux.dev> Link: https://patch.msgid.link/20250710201454.1280277-1-sean.anderson@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-14net: phy: Don't register LEDs for genphySean Anderson
If a PHY has no driver, the genphy driver is probed/removed directly in phy_attach/detach. If the PHY's ofnode has an "leds" subnode, then the LEDs will be (un)registered when probing/removing the genphy driver. This could occur if the leds are for a non-generic driver that isn't loaded for whatever reason. Synchronously removing the PHY device in phy_detach leads to the following deadlock: rtnl_lock() ndo_close() ... phy_detach() phy_remove() phy_leds_unregister() led_classdev_unregister() led_trigger_set() netdev_trigger_deactivate() unregister_netdevice_notifier() rtnl_lock() There is a corresponding deadlock on the open/register side of things (and that one is reported by lockdep), but it requires a race while this one is deterministic. Generic PHYs do not support LEDs anyway, so don't bother registering them. Fixes: 01e5b728e9e4 ("net: phy: Add a binding for PHY LEDs") Signed-off-by: Sean Anderson <sean.anderson@linux.dev> Link: https://patch.msgid.link/20250707195803.666097-1-sean.anderson@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-14netdevsim: implement peer queue flow controlBreno Leitao
Add flow control mechanism between paired netdevsim devices to stop the TX queue during high traffic scenarios. When a receive queue becomes congested (approaching NSIM_RING_SIZE limit), the corresponding transmit queue on the peer device is stopped using netif_subqueue_try_stop(). Once the receive queue has sufficient capacity again, the peer's transmit queue is resumed with netif_tx_wake_queue(). Key changes: * Add nsim_stop_peer_tx_queue() to pause peer TX when RX queue is full * Add nsim_start_peer_tx_queue() to resume peer TX when RX queue drains * Implement queue mapping validation to ensure TX/RX queue count match * Wake all queues during device unlinking to prevent stuck queues * Use RCU protection when accessing peer device references * wake the queues when changing the queue numbers * Remove IFF_NO_QUEUE given it will enqueue packets now The flow control only activates when devices have matching TX/RX queue counts to ensure proper queue mapping. Suggested-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20250711-netdev_flow_control-v3-1-aa1d5a155762@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-14selftests: net: add test for variable PMTU in broadcast routesOscar Maes
Added a test for variable PMTU in broadcast routes. This test uses iputils' ping and attempts to send a ping between two peers, which should result in a regular echo reply. This test will fail when the receiving peer does not receive the echo request due to a lack of packet fragmentation. Signed-off-by: Oscar Maes <oscmaes92@gmail.com> Link: https://patch.msgid.link/20250710142714.12986-2-oscmaes92@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-14net: ipv4: fix incorrect MTU in broadcast routesOscar Maes
Currently, __mkroute_output overrules the MTU value configured for broadcast routes. This buggy behaviour can be reproduced with: ip link set dev eth1 mtu 9000 ip route del broadcast 192.168.0.255 dev eth1 proto kernel scope link src 192.168.0.2 ip route add broadcast 192.168.0.255 dev eth1 proto kernel scope link src 192.168.0.2 mtu 1500 The maximum packet size should be 1500, but it is actually 8000: ping -b 192.168.0.255 -s 8000 Fix __mkroute_output to allow MTU values to be configured for for broadcast routes (to support a mixed-MTU local-area-network). Signed-off-by: Oscar Maes <oscmaes92@gmail.com> Link: https://patch.msgid.link/20250710142714.12986-1-oscmaes92@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-14Merge branch 'mlx5-next' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux Tariq Toukan says: ==================== mlx5-next updates 2025-07-14 * 'mlx5-next' of git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux: net/mlx5: IFC updates for disabled host PF net/mlx5: Expose disciplined_fr_counter through HCA capabilities in mlx5_ifc RDMA/mlx5: Fix UMR modifying of mkey page size net/mlx5: Expose HCA capability bits for mkey max page size ==================== Link: https://patch.msgid.link/1752481357-34780-1-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit (git 2.34.1) at 2025-09-12 13:03:09 +0000