mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
synced 2026-09-22 09:34:56 +02:00
4e37987362bcac8909f2d4b4458f3aa645e41641
1444343
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Jakub Kicinski
|
4e37987362 |
Merge branch 'mlx5-next' of git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux
Tariq Toukan says: ==================== mlx5-next updates 2026-04-29 * 'mlx5-next' of git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux: net/mlx5: Extend query_esw_functions output for multi-function support net/mlx5: Remove unused host_sf_enable field net/mlx5: Add function_id_type for enable/disable_hca cmds mlx5: Rename the vport number enums for host PF and VF ==================== Link: https://patch.msgid.link/20260429212747.224411-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
Jakub Kicinski
|
4eb407d9da |
Merge branch 'bridge-do-not-suppress-arp-probes-and-dad-ns-unconditionally'
Danielle Ratson says: ==================== bridge: Do not suppress ARP probes and DAD NS unconditionally When using bridge neighbor suppression in EVPN deployments, Duplicate Address Detection (DAD) is currently broken for both IPv4 (ARP probes) and IPv6 (DAD Neighbor Solicitations). This prevents proper address conflict detection across the VXLAN fabric. The neighbor suppression feature allows the bridge to reply to ARP/NS messages on behalf of remote hosts when FDB and neighbor entries exist, suppressing unnecessary flooding over the VXLAN overlay. However, the current implementation unconditionally suppresses ARP probes and DAD NS, which breaks DAD. For DAD to work correctly: - When the bridge doesn't know the answer: flood the probe/DAD packet to allow remote VTEPs to respond. - When the bridge knows the answer: reply to indicate the address is in use. This series fixes the issue by adjusting the early suppression checks to exclude ARP probes and DAD NS from unconditional suppression, allowing them to reach the normal FDB lookup path. Gratuitous ARP and IPv6 unsolicited-NA messages are still suppressed unconditionally as before. Patchset overview: Patch #1: Fixes the unconditional suppression. Patch #2: Adds selftests. ==================== Link: https://patch.msgid.link/20260429062405.1386417-1-danieller@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
 Danielle Ratson
|
a3f88d89f6 |
selftests: net: Add tests for ARP probe and DAD NS handling
Add test cases to verify that ARP probes and DAD Neighbor Solicitations are handled correctly by the bridge neighbor suppression feature. When neighbor suppression is enabled on a bridge VXLAN port, the bridge should reply to ARP/NS messages on behalf of remote hosts when both FDB and neighbor entries exist, and the answer is known. However, when either the FDB or the neighbor exists, ARP probes / DAD NS should be treated like regular ARP requests / NS and flood to VXLAN. Add two new test functions: neigh_suppress_arp_probe(): Tests ARP probe handling by triggering duplicate address detection using arping -D. Verifies that probes are flooded when the bridge doesn't know the answer, and suppressed when FDB and neighbor entries exist. neigh_suppress_dad_ns(): Tests DAD NS handling by constructing DAD NS packets using mausezahn and verifies correct flooding/suppression behavior. Before the previous patch: $ ./test_bridge_neigh_suppress.sh -t "neigh_suppress_arp_probe neigh_suppress_dad_ns" Per-port ARP probe suppression ------------------------------ TEST: ARP probe suppression [ OK ] TEST: "neigh_suppress" is on [ OK ] TEST: ARP probe suppression [FAIL] TEST: FDB and neighbor entry installation [ OK ] TEST: arping [FAIL] TEST: ARP probe suppression [FAIL] TEST: neighbor removal [ OK ] TEST: ARP probe suppression [FAIL] TEST: "neigh_suppress" is off [ OK ] TEST: ARP probe suppression [FAIL] Per-port DAD NS suppression --------------------------- TEST: DAD NS suppression [ OK ] TEST: "neigh_suppress" is on [ OK ] TEST: DAD NS suppression [FAIL] TEST: FDB and neighbor entry installation [ OK ] TEST: DAD NS suppression [FAIL] TEST: neighbor removal [ OK ] TEST: DAD NS suppression [FAIL] TEST: DAD NS proxy NA reply [FAIL] TEST: "neigh_suppress" is off [ OK ] TEST: DAD NS suppression [FAIL] Tests passed: 10 Tests failed: 10 After the previous patch: $ ./test_bridge_neigh_suppress.sh -t "neigh_suppress_arp_probe neigh_suppress_dad_ns" Per-port ARP probe suppression ------------------------------ TEST: ARP probe suppression [ OK ] TEST: "neigh_suppress" is on [ OK ] TEST: ARP probe suppression [ OK ] TEST: FDB and neighbor entry installation [ OK ] TEST: arping [ OK ] TEST: ARP probe suppression [ OK ] TEST: neighbor removal [ OK ] TEST: ARP probe suppression [ OK ] TEST: "neigh_suppress" is off [ OK ] TEST: ARP probe suppression [ OK ] Per-port DAD NS suppression --------------------------- TEST: DAD NS suppression [ OK ] TEST: "neigh_suppress" is on [ OK ] TEST: DAD NS suppression [ OK ] TEST: FDB and neighbor entry installation [ OK ] TEST: DAD NS suppression [ OK ] TEST: neighbor removal [ OK ] TEST: DAD NS suppression [ OK ] TEST: DAD NS proxy NA reply [ OK ] TEST: "neigh_suppress" is off [ OK ] TEST: DAD NS suppression [ OK ] Tests passed: 20 Tests failed: 0 Signed-off-by: Danielle Ratson <danieller@nvidia.com> Acked-by: Nikolay Aleksandrov <razor@blackwall.org> Link: https://patch.msgid.link/20260429062405.1386417-3-danieller@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
Danielle Ratson
|
fee1fc1d5a |
bridge: Do not suppress ARP probes and DAD NS unconditionally
When neighbor suppression is enabled on a VXLAN port, the bridge is
expected to reply to ARP/NS messages on behalf of remote hosts when both
FDB and neighbor entries exist. This allows the bridge to suppress
flooding of these messages to the VXLAN overlay.
According to RFC 9161 ("Operational Aspects of Proxy ARP/ND in Ethernet
Virtual Private Networks"):
"A PE SHOULD reply to broadcast/multicast address resolution messages,
i.e., ARP Requests, ARP probes, NS messages, as well as DAD NS messages.
An ARP probe is an ARP Request constructed with an all-zero sender IP
address that may be used by hosts for IPv4 Address Conflict Detection as
specified in [RFC5227]".
However, the current implementation unconditionally suppresses ARP probes
and DAD Neighbor Solicitations, which breaks Duplicate Address Detection
(DAD) over EVPN.
For DAD to work correctly over the VXLAN fabric:
- When the bridge does not know the answer:
flood the probe/DAD packet to allow remote VTEPs to respond.
- When the bridge knows the answer:
reply to indicate the address is in use.
Fix by adjusting the early suppression checks to exclude ARP probes and
DAD NS from unconditional suppression.
When replying to a DAD NS, br_nd_send() is adjusted to set the NA
destination to the all-nodes multicast address (ff02::1) and clear the
Solicited flag, in accordance with RFC 4861 section 7.2.4.
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Danielle Ratson <danieller@nvidia.com>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Link: https://patch.msgid.link/20260429062405.1386417-2-danieller@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
||
 D. Wythe
|
4cc5130ee8 |
net/smc: cap allocation order for SMC-R physically contiguous buffers
The alloc_pages() cannot satisfy requests exceeding MAX_PAGE_ORDER, and attempting such allocations will lead to guaranteed failures and potential kernel warnings. For SMCR_PHYS_CONT_BUFS, cap the allocation order to MAX_PAGE_ORDER. This ensures the attempts to allocate the largest possible physically contiguous chunk succeed, instead of failing with an invalid order. This also avoids redundant "try-fail-degrade" cycles in __smc_buf_create(). For SMCR_MIXED_BUFS, no cap is needed: if the order exceeds MAX_PAGE_ORDER, alloc_pages() will silently fail (__GFP_NOWARN) and automatically fall back to virtual memory. Signed-off-by: D. Wythe <alibuda@linux.alibaba.com> Reviewed-by: Dust Li <dust.li@linux.alibaba.com> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Sidraya Jayagond <sidraya@linux.ibm.com> Link: https://patch.msgid.link/20260429021637.21815-1-alibuda@linux.alibaba.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
Jakub Kicinski
|
6855a52318 |
Merge tag 'wireless-next-2026-04-30' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next
Johannes Berg says:
====================
Some new content already, notably:
- mac80211: major rework of station bandwidth handling,
fixing issues with lower capability than AP
- general: cleanups for EMLSR spec issues (drafts differed)
- ath9k: GPIO interface improvements
- ath12k: replace dynamic memory allocation in WMI RX path
* tag 'wireless-next-2026-04-30' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (39 commits)
wifi: brcmsmac: phy_lcn: Remove dead code in wlc_lcnphy_radio_2064_channel_tune_4313()
wifi: mac80211: always allow transmitting null-data on TXQs
wifi: mac80211: use kstrtobool_from_user() in debugfs callbacks
wifi: cfg80211: validate cipher suite for NAN Data keys
wifi: nl80211: check link is beaconing for color change
wifi: mac80211: clarify an 802.11 VHT spec reference
wifi: mac80211: fix per-station PHY capability bandwidth
wifi: mac80211: clarify per-STA bandwidth handling
wifi: nl80211: always validate AP operation/PHY regulatory
wifi: cfg80211: provide HT/VHT operation for AP beacon
wifi: nl80211: reject too short HT/VHT/HE/EHT capability/operation
wifi: cfg80211: move AP HT/VHT/... operation to beacon info
wifi: nl80211: reject beacons with bad HE operation
wifi: cfg80211: remove HE/SAE H2E required fields
wifi: mac80211: remove ieee80211_sta_cur_vht_bw()
wifi: mac80211: clean up ieee80211_sta_cap_rx_bw()
wifi: mac80211: clean up initial STA NSS/bandwidth handling
wifi: mac80211: clean up STA NSS handling
wifi: mac80211: simplify ieee80211_sta_rx_bw_to_chan_width()
wifi: nl80211: document channel opmode change channel width
...
====================
Link: https://patch.msgid.link/20260430120304.249081-3-johannes@sipsolutions.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
||
 Jeremy Kerr
|
8ca4bff2ff |
net: mctp: test: remove skb dumps from test output
We're currently dumping skb info in our fragment input test, which makes interpreting the TAP test output a bit awkward. Remove the skb dumps. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260429-dev-mctp-test-skb-dump-v1-1-13fd5789ef71@codeconstruct.com.au Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
Jakub Kicinski
|
7c04aa3b2f |
Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
Cross-merge networking fixes after downstream PR (net-7.1-rc2). No conflicts, or adjacent changes. Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
 Linus Torvalds
|
08d0d34666 |
Merge tag 'net-7.1-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
Pull networking fixes from Paolo Abeni:
"Including fixes from netfilter.
Current release - regressions:
- ipmr: free mr_table after RCU grace period.
Previous releases - regressions:
- core: add net_iov_init() and use it to initialize ->page_type
- sched: taprio: fix NULL pointer dereference in class dump
- netfilter: nf_tables:
- use list_del_rcu for netlink hooks
- fix strict mode inbound policy matching
- tcp: make probe0 timer handle expired user timeout
- vrf: fix a potential NPD when removing a port from a VRF
- eth: ice:
- fix NULL pointer dereference in ice_reset_all_vfs()
- fix infinite recursion in ice_cfg_tx_topo via ice_init_dev_hw
Previous releases - always broken:
- page_pool: fix memory-provider leak in error path
- sched: sch_cake: annotate data-races in cake_dump_stats()
- mptcp: fix scheduling with atomic in timestamp sockopt
- psp: check for device unregister when creating assoc
- tls: fix strparser anchor skb leak on offload RX setup failure
- eth:
- stmmac: prevent NULL deref when RX memory exhausted
- airoha: do not read uninitialized fragment address
- rtl8150: fix use-after-free in rtl8150_start_xmit()
Misc:
- add Ido Schimmel as IPv4/IPv6 maintainer
- add David Heidelberg as NFC subsystem maintainer"
* tag 'net-7.1-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (79 commits)
net/sched: cls_flower: revert unintended changes
sfc: fix error code in efx_devlink_info_running_versions()
net: tls: fix strparser anchor skb leak on offload RX setup failure
ice: add dpll peer notification for paired SMA and U.FL pins
ice: fix missing dpll notifications for SW pins
dpll: export __dpll_pin_change_ntf() for use under dpll_lock
ice: fix SMA and U.FL pin state changes affecting paired pin
ice: fix missing SMA pin initialization in DPLL subsystem
ice: fix infinite recursion in ice_cfg_tx_topo via ice_init_dev_hw
ice: fix NULL pointer dereference in ice_reset_all_vfs()
iavf: add VIRTCHNL_OP_ADD_VLAN to success completion handler
iavf: wait for PF confirmation before removing VLAN filters
iavf: stop removing VLAN filters from PF on interface down
iavf: rename IAVF_VLAN_IS_NEW to IAVF_VLAN_ADDING
page_pool: fix memory-provider leak in page_pool_create_percpu() error path
bonding: 3ad: implement proper RCU rules for port->aggregator
net: airoha: Do not return err in ndo_stop() callback
hv_sock: fix ARM64 support
MAINTAINERS: update the IPv4/IPv6 entry and add Ido Schimmel
selftests: drv-net: clarify linters and frameworks in README
...
|
||
|
Linus Torvalds
|
6cd70263a6 |
Merge tag 'ata-7.1-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux
Pull ata fix from Niklas Cassel: - Fix a reference leak on device_register() failure in pata_parport * tag 'ata-7.1-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux: ata: pata_parport: switch to dynamic root device |
||
|
Linus Torvalds
|
2aa0a36917 |
Merge tag 'sound-7.1-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"A bunch of small fixes. One minor fix is found in the core side for
data race in PCM OSS layer, while remaining changes are various
device-specific fixes and quirks.
- Core: PCM OSS data race fix
- HD-audio: Fixes for TAS2781, CS35L56, and Realtek/Conexant quirks;
avoidance of a WARN_ON for HDMI channel mapping
- USB-audio: Improvements in UAC3 parsing robustness (leaks, size
checks) and fixes for potential endless loops
- ASoC: Driver-specific fixes for CS35L56, Intel bytcr_wm5102,
Spacemit, AW88395, and others, plus a new quirk for Steam Deck
OLED
- Misc: A UAF fix in aloop driver, division by zero fix in ua101
driver and leak fixes in caiaq driver"
* tag 'sound-7.1-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (32 commits)
ALSA: hda/tas2781: Fix incorrect bit update for non-book-zero or book 0 pages >1
ALSA: hda: cs35l56: Fix uninitialized value in cs35l56_hda_read_acpi()
ALSA: hda/conexant: Fix missing error check for jack detection
ALSA: hda: Avoid WARN_ON() for HDMI chmap slot checks
ALSA: usb-audio: Fix quirk entry placement for PreSonus AudioBox USB
ASoC: spacemit: adjust FIFO trigger threshold to half FIFO size
ASoC: spacemit: move hw constraints from hw_params to startup
ASoC: codecs: ab8500: Fix casting of private data
ASoC: cs35l56: Fix illegal writes to OTP_MEM registers
ASoC: Intel: bytcr_wm5102: Fix MCLK leak on platform_clock_control error
ALSA: usb-audio: Avoid potential endless loop in convert_chmap_v3()
ALSA: usb-audio: Fix potential leak of pd at parsing UAC3 streams
ALSA: caiaq: Don't abort when no input device is available
ALSA: caiaq: Fix potentially leftover ep1_in_urb at error path
ASoC: aw88395: Fix kernel panic caused by invalid GPIO error pointer
ALSA: caiaq: fix usb_dev refcount leak on probe failure
sound: ua101: fix division by zero at probe
ALSA: usb-audio: apply quirk for Playstation PDP Riffmaster
ALSA: hda: Remove duplicate cmedia entries in codecs Makefile
ALSA: hda/realtek: Add micmute LED quirk for Acer Aspire A315-44P
...
|
||
 Paolo Abeni
|
82968921d2 |
Merge branch 'dpll-add-pin-operational-state'
Ivan Vecera says: ==================== dpll: add pin operational state Add pin operational state (operstate) to the DPLL subsystem to separate administrative intent from actual hardware status. Currently pin-state mixes what the user requested (connected, selectable, disconnected) with what the hardware is actually doing. This makes it difficult to diagnose situations where a user sets a pin as selectable or connected but the hardware cannot use it due to signal issues. The new operstate attribute is reported inside the pin-parent-device nest alongside the existing state and is read-only. Defined values: - active: pin is qualified and actively used by the DPLL - standby: pin is qualified but not actively used by the DPLL - no-signal: pin does not have a valid signal - qual-failed: pin signal failed qualification checks Patch 1 adds the operstate enum, netlink attribute and the operstate_on_dpll_get callback to the DPLL subsystem. It also updates Documentation/driver-api/dpll.rst to describe the separation between admin state and operational state. Patch 2 implements the callback for ZL3073x input pins using the reference monitor status register. It also refactors the existing state_on_dpll_get to return purely administrative state and switches periodic monitoring to track operstate changes. ==================== Link: https://patch.msgid.link/20260428154907.2820654-1-ivecera@redhat.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> |
||
 Ivan Vecera
|
c53f8f8dce |
dpll: zl3073x: implement pin operational state reporting
Implement operstate_on_dpll_get callback for input pins to report
the actual hardware status:
- active: pin is the currently locked reference
- standby: signal is valid but pin is not actively used
- no-signal: reference monitor reports Loss of Signal (LOS)
- qual-failed: reference monitor reports a qualification failure
(SCM, CFM, GST, PFM, eSync or Split-XO)
Separate administrative state (state_on_dpll_get) from operational
state: admin state now reports purely the user-requested intent
(connected in reflock mode, selectable in auto mode).
Switch periodic monitoring to track operstate changes instead of
the mixed admin/oper state that was previously reported.
Add ref_mon_status bit definitions to regs.h.
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Reviewed-by: Petr Oros <poros@redhat.com>
Link: https://patch.msgid.link/20260428154907.2820654-3-ivecera@redhat.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
||
|
Ivan Vecera
|
781c8893a5 |
dpll: add pin operational state
Add pin-operstate enum and operstate_on_dpll_get callback to report the actual hardware status of a pin with respect to its parent DPLL device. Unlike pin-state (which reflects administrative intent set by the user), operstate reflects what the hardware is actually doing. Defined operational states: - active: pin is qualified and actively used by the DPLL - standby: pin is qualified but not actively used by the DPLL - no-signal: pin does not have a valid signal - qual-failed: pin signal failed qualification The operstate is reported inside the pin-parent-device nested attribute alongside the existing state and phase-offset attributes. Signed-off-by: Ivan Vecera <ivecera@redhat.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Reviewed-by: Petr Oros <poros@redhat.com> Link: https://patch.msgid.link/20260428154907.2820654-2-ivecera@redhat.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> |
||
|
Paolo Abeni
|
1e01abec85 |
net/sched: cls_flower: revert unintended changes
While applying the blamed commit |
||
 Dan Carpenter
|
051ffb001b |
sfc: fix error code in efx_devlink_info_running_versions()
Return -EIO if efx_mcdi_rpc() doesn't return enough space.
Fixes:
|
||
|
Jakub Kicinski
|
58689498ca |
net: tls: fix strparser anchor skb leak on offload RX setup failure
When tls_set_device_offload_rx() fails at tls_dev_add(), the error path calls tls_sw_free_resources_rx() to clean up the SW context that was initialized by tls_set_sw_offload(). This function calls tls_sw_release_resources_rx() (which stops the strparser via tls_strp_stop()) and tls_sw_free_ctx_rx() (which kfrees the context), but never frees the anchor skb that was allocated by alloc_skb(0) in tls_strp_init(). Note that tls_sw_free_resources_rx() is exclusively used for this "failed to start offload" code path, there's no other caller. The leak did not exist before commit |
||
|
Paolo Abeni
|
47888597a3 |
Merge branch 'intel-wired-lan-update-2026-04-27-ice-iavf'
Jacob Keller says: ==================== Intel Wired LAN Update 2026-04-27 (ice, iavf) Petr Oros from RedHat has accumulated a number of fixes for the Intel ice and iavf drivers, bundled together in this series. First, a series of 4 fixes to resolve issues with the iavf driver logic for handling VLAN filters. This includes keeping VLAN filters while the interface is brought down, waiting for confirmation on filter deletion before deleting filters from the driver tracking structures, and handling the VIRTCHNL_OP_ADD_VLAN for the old v1 VLAN_ADD command. A fix for a crash in ice_reset_all_vfs(), properly checking for errors when ice_vf_rebuild_vsi() fails. A fix for a possible infinite recursion in ice_cfg_tx_topo() that occurs when trying to apply invalid Tx topology configuration. A fix to initialize the SMA pins in the DPLL subsystem properly. A fix to change the SMA and U.FL pin state for paired pins, ensuring that all flows changing one pin will also update its shared pin appropriately. A preparatory patch to export __dpll_pin_change_ntf() so that drivers can notify pin changes while already holding the dpll_lock. A fix to ensure DPLL notifications are sent for the software-controlled pins which wrap the physical CGU input/output pins. A fix to add DPLL notifications for peer pins when changing the SMA or U.FL pins, ensuring DPLL subsystem is notified about the paired connected pins. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> ==================== Link: https://patch.msgid.link/20260427-jk-iwl-net-petr-oros-fixes-v1-0-cdcb48303fd8@intel.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> |
||
 Petr Oros
|
9e5dead140 |
ice: add dpll peer notification for paired SMA and U.FL pins
SMA and U.FL pins share physical signal paths in pairs (SMA1/U.FL1 and
SMA2/U.FL2). When one pin's state changes via a PCA9575 GPIO write,
the paired pin's state also changes, but no notification is sent for
the peer pin. Userspace consumers monitoring the peer via dpll netlink
subscribe never learn about the update.
Add ice_dpll_sw_pin_notify_peer() which sends a change notification for
the paired SW pin. Call it from ice_dpll_pin_sma_direction_set(),
ice_dpll_sma_pin_state_set(), and ice_dpll_ufl_pin_state_set() after
pf->dplls.lock is released. Use __dpll_pin_change_ntf() because
dpll_lock is still held by the dpll netlink layer (dpll_pin_pre_doit).
Fixes:
|
||
|
Petr Oros
|
1a41b58fd4 |
ice: fix missing dpll notifications for SW pins
The SMA/U.FL pin redesign (commit |
||
|
Ivan Vecera
|
620055cb10 |
dpll: export __dpll_pin_change_ntf() for use under dpll_lock
Export __dpll_pin_change_ntf() so that drivers can send pin change notifications from within pin callbacks, which are already called under dpll_lock. Using dpll_pin_change_ntf() in that context would deadlock. Add lockdep_assert_held() to catch misuse without the lock held. Acked-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Signed-off-by: Ivan Vecera <ivecera@redhat.com> Signed-off-by: Petr Oros <poros@redhat.com> Tested-by: Alexander Nowlin <alexander.nowlin@intel.com> Reviewed-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260427-jk-iwl-net-petr-oros-fixes-v1-9-cdcb48303fd8@intel.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> |
||
|
Petr Oros
|
6f9d8393c9 |
ice: fix SMA and U.FL pin state changes affecting paired pin
SMA and U.FL pins share physical signal paths in pairs (SMA1/U.FL1 and
SMA2/U.FL2) controlled by the PCA9575 GPIO expander. Each pair can
only have one active pin at a time: SMA1 output and U.FL1 output share
the same CGU output, SMA2 input and U.FL2 input share the same CGU
input. The PCA9575 register bits determine which connector in each
pair owns the signal path.
The driver does not account for this pairing in two places:
ice_dpll_ufl_pin_state_set() modifies PCA9575 bits and disables the
backing CGU pin without checking whether the U.FL pin is currently
active. Disconnecting an already inactive U.FL pin flips bits that
the paired SMA pin relies on, breaking its connection.
ice_dpll_sma_direction_set() does not propagate direction changes to
the paired U.FL pin. For SMA2/U.FL2 the ICE_SMA2_UFL2_RX_DIS bit is
never managed, so U.FL2 stays disconnected after SMA2 switches to
output. For both pairs the backing CGU pin of the U.FL side is never
enabled when a direction change activates it, so userspace sees the
pin as disconnected even though the routing is correct.
Fix by guarding the U.FL disconnect path against inactive pins and by
updating the paired U.FL pin fully on SMA direction changes: manage
ICE_SMA2_UFL2_RX_DIS for the SMA2/U.FL2 pair and enable the backing
CGU pin whenever the peer becomes active.
Fixes:
|
||
|
Petr Oros
|
56a643aed0 |
ice: fix missing SMA pin initialization in DPLL subsystem
The DPLL SMA/U.FL pin redesign introduced ice_dpll_sw_pin_frequency_get()
which gates frequency reporting on the pin's active flag. This flag is
determined by ice_dpll_sw_pins_update() from the PCA9575 GPIO expander
state. Before the redesign, SMA pins were exposed as direct HW
input/output pins and ice_dpll_frequency_get() returned the CGU
frequency unconditionally — the PCA9575 state was never consulted.
The PCA9575 powers on with all outputs high, setting ICE_SMA1_DIR_EN,
ICE_SMA1_TX_EN, ICE_SMA2_DIR_EN and ICE_SMA2_TX_EN. Nothing in the
driver writes the register during initialization, so
ice_dpll_sw_pins_update() sees all pins as inactive and
ice_dpll_sw_pin_frequency_get() permanently returns 0 Hz for every
SW pin.
Fix this by writing a default SMA configuration in
ice_dpll_init_info_sw_pins(): clear all SMA bits, then set SMA1 and
SMA2 as active inputs (DIR_EN=0) with U.FL1 output and U.FL2 input
disabled. Each SMA/U.FL pair shares a physical signal path so only
one pin per pair can be active at a time. U.FL pins still report
frequency 0 after this fix: U.FL1 (output-only) is disabled by
ICE_SMA1_TX_EN which keeps the TX output buffer off, and U.FL2
(input-only) is disabled by ICE_SMA2_UFL2_RX_DIS. They can be
activated by changing the corresponding SMA pin direction via dpll
netlink.
Fixes:
|
||
|
Petr Oros
|
70ad216411 |
ice: fix infinite recursion in ice_cfg_tx_topo via ice_init_dev_hw
On certain E810 configurations where firmware supports Tx scheduler topology switching (tx_sched_topo_comp_mode_en), ice_cfg_tx_topo() may need to apply a new 5-layer or 9-layer topology from the DDP package. If the AQ command to set the topology fails (e.g. due to invalid DDP data or firmware limitations), the global configuration lock must still be cleared via a CORER reset. Commit |
||
|
Petr Oros
|
54ef024879 |
ice: fix NULL pointer dereference in ice_reset_all_vfs()
ice_reset_all_vfs() ignores the return value of ice_vf_rebuild_vsi().
When the VSI rebuild fails (e.g. during NVM firmware update via
nvmupdate64e), ice_vsi_rebuild() tears down the VSI on its error path,
leaving txq_map and rxq_map as NULL. The subsequent unconditional call
to ice_vf_post_vsi_rebuild() leads to a NULL pointer dereference in
ice_ena_vf_q_mappings() when it accesses vsi->txq_map[0].
The single-VF reset path in ice_reset_vf() already handles this
correctly by checking the return value of ice_vf_reconfig_vsi() and
skipping ice_vf_post_vsi_rebuild() on failure.
Apply the same pattern to ice_reset_all_vfs(): check the return value
of ice_vf_rebuild_vsi() and skip ice_vf_post_vsi_rebuild() and
ice_eswitch_attach_vf() on failure. The VF is left safely disabled
(ICE_VF_STATE_INIT not set, VFGEN_RSTAT not set to VFACTIVE) and can
be recovered via a VFLR triggered by a PCI reset of the VF
(sysfs reset or driver rebind).
Note that this patch does not prevent the VF VSI rebuild from failing
during NVM update — the underlying cause is firmware being in a
transitional state while the EMP reset is processed, which can cause
Admin Queue commands (ice_add_vsi, ice_cfg_vsi_lan) to fail. This
patch only prevents the subsequent NULL pointer dereference that
crashes the kernel when the rebuild does fail.
crash> bt
PID: 50795 TASK: ff34c9ee708dc680 CPU: 1 COMMAND: "kworker/u512:5"
#0 [ff72159bcfe5bb50] machine_kexec at ffffffffaa8850ee
#1 [ff72159bcfe5bba8] __crash_kexec at ffffffffaaa15fba
#2 [ff72159bcfe5bc68] crash_kexec at ffffffffaaa16540
#3 [ff72159bcfe5bc70] oops_end at ffffffffaa837eda
#4 [ff72159bcfe5bc90] page_fault_oops at ffffffffaa893997
#5 [ff72159bcfe5bce8] exc_page_fault at ffffffffab528595
#6 [ff72159bcfe5bd10] asm_exc_page_fault at ffffffffab600bb2
[exception RIP: ice_ena_vf_q_mappings+0x79]
RIP: ffffffffc0a85b29 RSP: ff72159bcfe5bdc8 RFLAGS: 00010206
RAX: 00000000000f0000 RBX: ff34c9efc9c00000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000010 RDI: ff34c9efc9c00000
RBP: ff34c9efc27d4828 R8: 0000000000000093 R9: 0000000000000040
R10: ff34c9efc27d4828 R11: 0000000000000040 R12: 0000000000100000
R13: 0000000000000010 R14: R15:
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
#7 [ff72159bcfe5bdf8] ice_sriov_post_vsi_rebuild at ffffffffc0a85e2e [ice]
#8 [ff72159bcfe5be08] ice_reset_all_vfs at ffffffffc0a920b4 [ice]
#9 [ff72159bcfe5be48] ice_service_task at ffffffffc0a31519 [ice]
#10 [ff72159bcfe5be88] process_one_work at ffffffffaa93dca4
#11 [ff72159bcfe5bec8] worker_thread at ffffffffaa93e9de
#12 [ff72159bcfe5bf18] kthread at ffffffffaa946663
#13 [ff72159bcfe5bf50] ret_from_fork at ffffffffaa8086b9
The panic occurs attempting to dereference the NULL pointer in RDX at
ice_sriov.c:294, which loads vsi->txq_map (offset 0x4b8 in ice_vsi).
The faulting VSI is an allocated slab object but not fully initialized
after a failed ice_vsi_rebuild():
crash> struct ice_vsi 0xff34c9efc27d4828
netdev = 0x0,
rx_rings = 0x0,
tx_rings = 0x0,
q_vectors = 0x0,
txq_map = 0x0,
rxq_map = 0x0,
alloc_txq = 0x10,
num_txq = 0x10,
alloc_rxq = 0x10,
num_rxq = 0x10,
The nvmupdate64e process was performing NVM firmware update:
crash> bt 0xff34c9edd1a30000
PID: 49858 TASK: ff34c9edd1a30000 CPU: 1 COMMAND: "nvmupdate64e"
#0 [ff72159bcd617618] __schedule at ffffffffab5333f8
#4 [ff72159bcd617750] ice_sq_send_cmd at ffffffffc0a35347 [ice]
#5 [ff72159bcd6177a8] ice_sq_send_cmd_retry at ffffffffc0a35b47 [ice]
#6 [ff72159bcd617810] ice_aq_send_cmd at ffffffffc0a38018 [ice]
#7 [ff72159bcd617848] ice_aq_read_nvm at ffffffffc0a40254 [ice]
#8 [ff72159bcd6178b8] ice_read_flat_nvm at ffffffffc0a4034c [ice]
#9 [ff72159bcd617918] ice_devlink_nvm_snapshot at ffffffffc0a6ffa5 [ice]
dmesg:
ice 0000:13:00.0: firmware recommends not updating fw.mgmt, as it
may result in a downgrade. continuing anyways
ice 0000:13:00.1: ice_init_nvm failed -5
ice 0000:13:00.1: Rebuild failed, unload and reload driver
Fixes:
|
||
|
Petr Oros
|
34d33313b5 |
iavf: add VIRTCHNL_OP_ADD_VLAN to success completion handler
The V1 ADD_VLAN opcode had no success handler; filters sent via V1
stayed in ADDING state permanently. Add a fallthrough case so V1
filters also transition ADDING -> ACTIVE on PF confirmation.
Critically, add an `if (v_retval) break` guard: the error switch in
iavf_virtchnl_completion() does NOT return after handling errors,
it falls through to the success switch. Without this guard, a
PF-rejected ADD would incorrectly mark ADDING filters as ACTIVE,
creating a driver/HW mismatch where the driver believes the filter
is installed but the PF never accepted it.
For V2, this is harmless: iavf_vlan_add_reject() in the error
block already kfree'd all ADDING filters, so the success handler
finds nothing to transition.
Fixes:
|
||
|
Petr Oros
|
bbcbe4ed70 |
iavf: wait for PF confirmation before removing VLAN filters
The VLAN filter DELETE path was asymmetric with the ADD path: ADD
waits for PF confirmation (ADD -> ADDING -> ACTIVE), but DELETE
immediately frees the filter struct after sending the DEL message
without waiting for the PF response.
This is problematic because:
- If the PF rejects the DEL, the filter remains in HW but the driver
has already freed the tracking structure, losing sync.
- Race conditions between DEL pending and other operations
(add, reset) cannot be properly resolved if the filter struct
is already gone.
Add IAVF_VLAN_REMOVING state to make the DELETE path symmetric:
REMOVE -> REMOVING (send DEL) -> PF confirms -> kfree
-> PF rejects -> ACTIVE
In iavf_del_vlans(), transition filters from REMOVE to REMOVING
instead of immediately freeing them. The new DEL completion handler
in iavf_virtchnl_completion() frees filters on success or reverts
them to ACTIVE on error.
Update iavf_add_vlan() to handle the REMOVING state: if a DEL is
pending and the user re-adds the same VLAN, queue it for ADD so
it gets re-programmed after the PF processes the DEL.
The !VLAN_FILTERING_ALLOWED early-exit path still frees filters
directly since no PF message is sent in that case.
Also update iavf_del_vlan() to skip filters already in REMOVING
state: DEL has been sent to PF and the completion handler will
free the filter when PF confirms. Without this guard, the sequence
DEL(pending) -> user-del -> second DEL could cause the PF to return
an error for the second DEL (filter already gone), causing the
completion handler to incorrectly revert a deleted filter back to
ACTIVE.
Fixes:
|
||
|
Petr Oros
|
f2ce65b9b9 |
iavf: stop removing VLAN filters from PF on interface down
When a VF goes down, the driver currently sends DEL_VLAN to the PF for
every VLAN filter (ACTIVE -> DISABLE -> send DEL -> INACTIVE), then
re-adds them all on UP (INACTIVE -> ADD -> send ADD -> ADDING ->
ACTIVE). This round-trip is unnecessary because:
1. The PF disables the VF's queues via VIRTCHNL_OP_DISABLE_QUEUES,
which already prevents all RX/TX traffic regardless of VLAN filter
state.
2. The VLAN filters remaining in PF HW while the VF is down is
harmless - packets matching those filters have nowhere to go with
queues disabled.
3. The DEL+ADD cycle during down/up creates race windows where the
VLAN filter list is incomplete. With spoofcheck enabled, the PF
enables TX VLAN filtering on the first non-zero VLAN add, blocking
traffic for any VLANs not yet re-added.
Remove the entire DISABLE/INACTIVE state machinery:
- Remove IAVF_VLAN_DISABLE and IAVF_VLAN_INACTIVE enum values
- Remove iavf_restore_filters() and its call from iavf_open()
- Remove VLAN filter handling from iavf_clear_mac_vlan_filters(),
rename it to iavf_clear_mac_filters()
- Remove DEL_VLAN_FILTER scheduling from iavf_down()
- Remove all DISABLE/INACTIVE handling from iavf_del_vlans()
VLAN filters now stay ACTIVE across down/up cycles. Only explicit
user removal (ndo_vlan_rx_kill_vid) or PF/VF reset triggers VLAN
filter deletion/re-addition.
Fixes:
|
||
|
Petr Oros
|
70d62b669f |
iavf: rename IAVF_VLAN_IS_NEW to IAVF_VLAN_ADDING
Rename the IAVF_VLAN_IS_NEW state to IAVF_VLAN_ADDING to better describe what the state represents: an ADD request has been sent to the PF and is waiting for a response. This is a pure rename with no behavioral change, preparing for a cleanup of the VLAN filter state machine. Signed-off-by: Petr Oros <poros@redhat.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260427-jk-iwl-net-petr-oros-fixes-v1-1-cdcb48303fd8@intel.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> |
||
|
Paolo Abeni
|
fdd2c9a1d0 |
Merge branch 'reimplement-tcp-ao-using-crypto-library'
Eric Biggers says:
====================
Reimplement TCP-AO using crypto library
This series can also be retrieved from:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git tcp-ao-v2
This series is targeting net-next for 7.2. To make this series
self-contained in the networking code, I dropped the patches that remove
support for transformation cloning from the crypto API, which is a
further negative 275-line cleanup and optimization this series enables.
That will be done as a follow-up, either through the crypto tree for
7.3, or still through net-next for 7.2 at maintainer preference.
This series refactors the TCP-AO (TCP Authentication Option) code to do
MAC and KDF computations using lib/crypto/ instead of crypto_ahash.
This greatly simplifies the code and makes it much more efficient. The
entire tcp_sigpool mechanism becomes unnecessary and is removed, as the
problems it was designed to solve don't exist with the library APIs.
The crypto API's support for crypto transformation cloning also becomes
unnecessary and will be removed in follow-up patches. Note that as part
of that, we'll be able to roll back the addition of the reference count
to crypto_tfm, which had regressed performance for all crypto API users.
To make this simplification and optimization possible, this series also
updates the TCP-AO code to support a specific set of algorithms, rather
than arbitrary algorithms that don't make sense and are very likely not
being used, e.g. CRC-32 and HMAC-MD5.
Specifically, this series retains the support for AES-128-CMAC,
HMAC-SHA1, and HMAC-SHA256. AES-128-CMAC and HMAC-SHA1 are the only
algorithms that are actually standardized for use in TCP-AO, while
HMAC-SHA256 makes sense to continue supporting as a Linux extension. Of
course, other algorithms can still be (re-)added later if ever needed.
It's worth noting that TCP-AO MACs are limited to 20 bytes by the TCP
options space, which limits the benefit of further algorithm upgrades.
This series passes the tcp_ao selftests
(sudo make -C tools/testing/selftests/net/tcp_ao/ run_tests).
To get a sense for how much more efficient this makes the TCP-AO code,
here's a microbenchmark for tcp_ao_hash_skb() with skb->len == 128:
Algorithm Avg cycles (before) Avg cycles (after)
--------- ------------------- ------------------
HMAC-SHA1 3319 1256
HMAC-SHA256 3311 1344
AES-128-CMAC 2720 1107
====================
Link: https://patch.msgid.link/20260427172727.9310-1-ebiggers@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
||
 Eric Biggers
|
4baf241599 |
net/tcp: Remove tcp_sigpool
tcp_sigpool is no longer used. It existed only as a workaround for issues in the design of the crypto_ahash API, which have been avoided by switching to the much easier-to-use library APIs instead. Remove it. Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Eric Biggers <ebiggers@kernel.org> Link: https://patch.msgid.link/20260427172727.9310-6-ebiggers@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com> |
||
|
Eric Biggers
|
8e4f61e431 |
net/tcp-ao: Return void from functions that can no longer fail
Since tcp-ao now uses the crypto library API instead of crypto_ahash, and MACs and keys now have a statically-known maximum size, many tcp-ao functions can no longer fail. Propagate this change up into the return types of various functions. Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Eric Biggers <ebiggers@kernel.org> Link: https://patch.msgid.link/20260427172727.9310-5-ebiggers@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com> |
||
|
Eric Biggers
|
4816879989 |
net/tcp-ao: Use stack-allocated MAC and traffic_key buffers
Now that the maximum MAC and traffic key lengths are statically-known small values, allocate MACs and traffic keys on the stack instead of with kmalloc. This eliminates multiple failure-prone GFP_ATOMIC allocations. Note that some cases such as tcp_ao_prepare_reset() are left unchanged for now since they would require slightly wider changes. Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Eric Biggers <ebiggers@kernel.org> Link: https://patch.msgid.link/20260427172727.9310-4-ebiggers@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com> |
||
|
Eric Biggers
|
068f5a0095 |
net/tcp-ao: Use crypto library API instead of crypto_ahash
Currently the kernel's TCP-AO implementation does the MAC and KDF computations using the crypto_ahash API. This API is inefficient and difficult to use, and it has required extensive workarounds in the form of per-CPU preallocated objects (tcp_sigpool) to work at all. Let's use lib/crypto/ instead. This means switching to straightforward stack-allocated structures, virtually addressed buffers, and direct function calls. It also means removing quite a bit of error handling. This makes TCP-AO quite a bit faster. This also enables many additional cleanups, which later commits will handle: removing tcp-sigpool, removing support for crypto_tfm cloning, removing more error handling, and replacing more dynamically-allocated buffers with stack buffers based on the now-statically-known limits. Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Eric Biggers <ebiggers@kernel.org> Link: https://patch.msgid.link/20260427172727.9310-3-ebiggers@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com> |
||
|
Eric Biggers
|
5eb0cfedb2 |
net/tcp-ao: Drop support for most non-RFC-specified algorithms
RFC 5926 (https://datatracker.ietf.org/doc/html/rfc5926) specifies the use of AES-128-CMAC and HMAC-SHA1 with TCP-AO. This includes a specification for how traffic keys shall be derived for each algorithm. Support for any other algorithms with TCP-AO isn't standardized, though an expired Internet Draft (a work-in-progress document, not a standard) from 2019 does propose adding HMAC-SHA256 support: https://datatracker.ietf.org/doc/html/draft-nayak-tcp-sha2-03 Since both documents specify the KDF for each algorithm individually, it isn't necessarily clear how any other algorithm should be integrated. Nevertheless, the Linux implementation of TCP-AO allows userspace to specify the MAC algorithm as a string tcp_ao_add::alg_name naming either "cmac(aes128)" or an arbitrary algorithm in the crypto_ahash API. The set of valid strings is undocumented. The implementation assumes that "cmac(aes128)" is the only algorithm that requires an entropy extraction step and that all algorithms accept keys with length equal to the untruncated MAC; thus, arbitrary HMAC algorithms probably do work, but some other MAC algorithms like AES-256-CMAC have never actually worked. Unfortunately, this undocumented string allows many obsolete, insecure, or redundant algorithms. For example, "hmac(md5)" and the non-cryptographic "crc32" are accepted. It also ties the implementation to crypto_ahash and requires that most memory be dynamically allocated, making the implementation unnecessarily complex and inefficient. Still furthermore, this implementation requires the crypto API to support "transformation cloning", whose only user is this feature. Fortunately, it's very likely that only a few algorithms are actually used in practice. Let's restrict the set of allowed algorithms to "cmac(aes128)" (or "cmac(aes)" with keylen=16), "hmac(sha1)", and "hmac(sha256)". The first two are the actually standard ones, while HMAC-SHA256 seems like a reasonable algorithm to continue supporting as a Linux extension, considering the Internet Draft for it and the fact that SHA-256 is the usual choice of upgrade from the outdated SHA-1. If any other algorithm ever turns out to be needed, e.g. HMAC-SHA512, it can of course be (re-)added in library form. However, note that the TCP options space limits TCP-AO MACs to 20 bytes (160 bits) anyway, which limits the potential benefit of any further upgrade to the algorithm. Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Eric Biggers <ebiggers@kernel.org> Link: https://patch.msgid.link/20260427172727.9310-2-ebiggers@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com> |
||
|
Linus Torvalds
|
e75a43c7ce |
Merge tag 'trace-v7.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace
Pull tracing fixes from Steven Rostedt: - Fix inverted check of registering the stats for branch tracing When calling register_stat_tracer() which returns zero on success and negative on error, the callers were checking the return of zero as an error and printing a warning message. Because this was just a normal printk() message and not a WARN(), it wasn't caught in any testing. Fix the check to print the warning message when an error actually happens. - Fix a typo in a comment in tracepoint.h - Limit the size of event probes to 3K in size It is possible to create a dynamic event probe via the tracefs system that is greater than the max size of an event that the ring buffer can hold. This basically causes the event to become useless. Limit the size of an event probe to be 3K as that should be large enough to handle any dynamic events being created, and fits within the PAGE_SIZE sub-buffers of the ring buffer. * tag 'trace-v7.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: tracing/probes: Limit size of event probe to 3K tracepoint: Fix typo in tracepoint.h comment tracing: branch: Fix inverted check on stat tracer registration |
||
 Hasan Basbunar
|
5ef343614d |
page_pool: fix memory-provider leak in page_pool_create_percpu() error path
When page_pool_create_percpu() fails on page_pool_list(), it falls
through to its err_uninit: label, which calls page_pool_uninit().
At that point page_pool_init() has already taken two references
when the user requested PP_FLAG_ALLOW_UNREADABLE_NETMEM:
pool->mp_ops->init(pool)
static_branch_inc(&page_pool_mem_providers);
Neither is undone by page_pool_uninit(); both are only undone by
__page_pool_destroy() (success-side teardown). The error path
therefore leaks the per-provider reference taken by mp_ops->init
(io_zcrx_ifq->refs in the io_uring zcrx provider, the dmabuf
binding refcount in the devmem provider) plus one increment of
the page_pool_mem_providers static branch on every failure of
xa_alloc_cyclic() inside page_pool_list().
The leaked io_zcrx_ifq->refs in turn pins everything
io_zcrx_ifq_free() would release on cleanup: ifq->user (uid),
ifq->mm_account (mmdrop), ifq->dev (device refcount),
ifq->netdev_tracker (netdev refcount), and the rbuf region.
The leaked static branch increment forces all subsequent
page_pool_alloc_netmems() and page_pool_return_page() callers to
take the slow mp_ops branch for the lifetime of the kernel.
Reachable via the io_uring zcrx path:
io_uring_register(IORING_REGISTER_ZCRX_IFQ) /* CAP_NET_ADMIN */
-> __io_uring_register
-> io_register_zcrx
-> zcrx_register_netdev
-> netif_mp_open_rxq
-> driver ndo_queue_mem_alloc
-> page_pool_create_percpu
-> page_pool_init succeeds (mp_ops->init runs, branch++)
-> page_pool_list fails (xa_alloc_cyclic -ENOMEM)
-> goto err_uninit <-- leak
The same shape applies to the devmem dmabuf provider via
mp_dmabuf_devmem_init()/mp_dmabuf_devmem_destroy().
Restore the cleanup symmetry by moving the mp_ops->destroy() and
static_branch_dec() calls out of __page_pool_destroy() and into
page_pool_uninit(), so page_pool_uninit() is again the strict
inverse of page_pool_init(). page_pool_uninit() has only two
callers (the err_uninit: path and __page_pool_destroy()), so this
preserves the single-call invariant on the success path while
fixing the err path. The error path of page_pool_init() itself
still skips the mp_ops cleanup correctly: mp_ops->init is the
last action that takes a reference before page_pool_init() returns
0, so when it returns an error neither the refcount nor the static
branch has been touched.
Triggering the bug requires xa_alloc_cyclic() to fail with -ENOMEM,
which under normal GFP_KERNEL retry behaviour is rare. It is
deterministic under CONFIG_FAULT_INJECTION with fail_page_alloc /
xa fault injection, or under sustained memory pressure. The leak
is silent: there is no warning, and the released kernel build
continues running with a permanently-incremented static branch.
Fixes:
|
||
 Eric Dumazet
|
28df22acc2 |
tcp: add tcp_mstamp_refresh_inline()
We want to inline tcp_mstamp_refresh() in fast path only: - tcp_rcv_established() - tcp_write_xmit() Add tcp_mstamp_refresh_inline() for this purpose. Add noinline qualifier on tcp_mstamp_refresh() for the other paths, to reduce bloat. $ scripts/bloat-o-meter -t vmlinux.old vmlinux.new add/remove: 0/0 grow/shrink: 1/4 up/down: 26/-123 (-97) Function old new delta tcp_rcv_established 2238 2264 +26 tcp_connect 4027 4003 -24 tcp_tsq_write 152 120 -32 tcp_send_active_reset 476 444 -32 tcp_send_window_probe 235 200 -35 Total: Before=25316710, After=25316613, chg -0.00% Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Neal Cardwell <ncardwell@google.com> Link: https://patch.msgid.link/20260429010809.784315-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
Eric Dumazet
|
c4f050ce06 |
bonding: 3ad: implement proper RCU rules for port->aggregator
syzbot found a data-race in bond_3ad_get_active_agg_info /
bond_3ad_state_machine_handler [1] which hints at lack of proper
RCU implementation.
Add __rcu qualifier to port->aggregator, and add proper RCU API.
[1]
BUG: KCSAN: data-race in bond_3ad_get_active_agg_info / bond_3ad_state_machine_handler
write to 0xffff88813cf5c4b0 of 8 bytes by task 36 on cpu 0:
ad_port_selection_logic drivers/net/bonding/bond_3ad.c:1659 [inline]
bond_3ad_state_machine_handler+0x9d5/0x2d60 drivers/net/bonding/bond_3ad.c:2569
process_one_work kernel/workqueue.c:3302 [inline]
process_scheduled_works+0x4f0/0x9c0 kernel/workqueue.c:3385
worker_thread+0x58a/0x780 kernel/workqueue.c:3466
kthread+0x22a/0x280 kernel/kthread.c:436
ret_from_fork+0x146/0x330 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
read to 0xffff88813cf5c4b0 of 8 bytes by task 22063 on cpu 1:
__bond_3ad_get_active_agg_info drivers/net/bonding/bond_3ad.c:2858 [inline]
bond_3ad_get_active_agg_info+0x8c/0x230 drivers/net/bonding/bond_3ad.c:2881
bond_fill_info+0xe0f/0x10f0 drivers/net/bonding/bond_netlink.c:853
rtnl_link_info_fill net/core/rtnetlink.c:906 [inline]
rtnl_link_fill+0x1d7/0x4e0 net/core/rtnetlink.c:927
rtnl_fill_ifinfo+0xf8e/0x1380 net/core/rtnetlink.c:2168
rtmsg_ifinfo_build_skb+0x11c/0x1b0 net/core/rtnetlink.c:4453
rtmsg_ifinfo_event net/core/rtnetlink.c:4486 [inline]
rtmsg_ifinfo+0x6d/0x110 net/core/rtnetlink.c:4495
__dev_notify_flags+0x76/0x390 net/core/dev.c:9790
netif_change_flags+0xac/0xd0 net/core/dev.c:9823
do_setlink+0x905/0x2950 net/core/rtnetlink.c:3180
rtnl_group_changelink net/core/rtnetlink.c:3813 [inline]
__rtnl_newlink net/core/rtnetlink.c:3981 [inline]
rtnl_newlink+0xf55/0x1400 net/core/rtnetlink.c:4109
rtnetlink_rcv_msg+0x64b/0x720 net/core/rtnetlink.c:6995
netlink_rcv_skb+0x123/0x220 net/netlink/af_netlink.c:2550
rtnetlink_rcv+0x1c/0x30 net/core/rtnetlink.c:7022
netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]
netlink_unicast+0x5a8/0x680 net/netlink/af_netlink.c:1344
netlink_sendmsg+0x5c8/0x6f0 net/netlink/af_netlink.c:1894
sock_sendmsg_nosec net/socket.c:787 [inline]
__sock_sendmsg net/socket.c:802 [inline]
____sys_sendmsg+0x563/0x5b0 net/socket.c:2698
___sys_sendmsg+0x195/0x1e0 net/socket.c:2752
__sys_sendmsg net/socket.c:2784 [inline]
__do_sys_sendmsg net/socket.c:2789 [inline]
__se_sys_sendmsg net/socket.c:2787 [inline]
__x64_sys_sendmsg+0xd4/0x160 net/socket.c:2787
x64_sys_call+0x194c/0x3020 arch/x86/include/generated/asm/syscalls_64.h:47
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x12c/0x3b0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
value changed: 0x0000000000000000 -> 0xffff88813cf5c400
Reported by Kernel Concurrency Sanitizer on:
CPU: 1 UID: 0 PID: 22063 Comm: syz.0.31122 Tainted: G W syzkaller #0 PREEMPT(full)
Tainted: [W]=WARN
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026
Fixes:
|
||
 Lorenzo Bianconi
|
4ca01292ea |
net: airoha: Do not return err in ndo_stop() callback
Always complete the airoha_dev_stop() routine regardless of the
airoha_set_vip_for_gdm_port() return value, since errors from
ndo_stop() are ignored by the networking stack and the interface is
always considered down after the call.
Fixes:
|
||
 Bartosz Golaszewski
|
c13581876f |
net: mdio: drop unneeded dependency on OF_GPIO
OF_GPIO is selected automatically on all OF systems. Any symbols it controls also provide stubs so there's really no reason to select it explicitly. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://patch.msgid.link/20260428093338.35043-1-bartosz.golaszewski@oss.qualcomm.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
Lorenzo Bianconi
|
c06a2f2903 |
net: airoha: Rename get_src_port_id callback in get_sport
For code consistency, rename get_src_port_id callback in get_sport. Please note this patch does not introduce any logical change and it is just a cosmetic patch. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20260428-airoha-get_src_port_id-callback-v1-1-3f765c91c1e8@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
 Birger Koblitz
|
b7ebbf9f7a |
r8152: Use ocp/mdio test and clear functions in r8157_hw_phy_cfg()
Replace explicit testing of bits and clearing these bits by existing functions ocp_word_test_and_clr_bits() and r8152_mdio_test_and_clr_bit() to re-use this code. This allows to remove the "ocp_data" variable. Also remove the "ret" variable which was incorrectly used for the r8153_phy_status() return value which is a u16, so that the remaining "data" variable is sufficient. Signed-off-by: Birger Koblitz <mail@birger-koblitz.de> Link: https://patch.msgid.link/20260428-use_bit_functions-v1-1-6eb5a3507610@birger-koblitz.de Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
Birger Koblitz
|
115553b80f |
r8152: Fix double consecutive clearing of PLA_MCU_SPDWN_EN bit
Due to a Copy & Paste Error, the PLA_MCU_SPDWN_EN bit was cleared twice consecutively using ocp_word_clr_bits. Fix that. Signed-off-by: Birger Koblitz <mail@birger-koblitz.de> Link: https://patch.msgid.link/20260428-patch_double-v1-1-27c830a9eb2e@birger-koblitz.de Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
Jakub Kicinski
|
b60f81e62b |
Merge branch 'net-mlx5-fix-e-switch-work-queue-deadlock-with-devlink-lock'
Tariq Toukan says: ==================== net/mlx5: Fix E-Switch work queue deadlock with devlink lock mlx5_eswitch_cleanup() calls destroy_workqueue() while holding the devlink lock through mlx5_uninit_one(). E-Switch workqueue workers also need the devlink lock, but previously took it before checking whether their work item was stale. Cleanup can therefore wait for a worker that is blocked on the same devlink lock. Mode changes have the same ordering hazard: the mode-change path holds devlink lock while tearing down the current mode, and old work may still be pending on the E-Switch workqueue. Fix this by making esw_wq_handler() check the generation counter before attempting to take devlink lock. The worker uses devl_trylock(); if the lock is busy and the work is still current, it sleeps on an E-Switch wait queue with a short timeout. Invalidation increments the generation counter and wakes the wait queue, so stale workers exit without spinning or blocking cleanup. The generation counter already existed but was buried in mlx5_esw_functions and only covered function-change events. The three patches get from there to the fix in small steps. Patch 1 moves the counter up to mlx5_eswitch. Pure refactor, no behavior change. Patch 2 cleans up the work queue plumbing: factors out the repeated lock/check/dispatch boilerplate into a single esw_wq_handler() and adds mlx5_esw_add_work() as the one place to enqueue work. Patch 3 is the actual fix: check the generation before the lock, use devl_trylock() instead of devl_lock(), add a wait queue so lock retries do not spin, and invalidate pending work at the earliest safe operation boundary. Cleanup invalidates before destroy_workqueue(), and mode teardown unregisters the work-producing notifiers before invalidating so new notifier work cannot capture the new generation. ==================== Link: https://patch.msgid.link/20260428051018.219093-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
 Mark Bloch
|
6a92fe1956 |
net/mlx5: E-Switch, fix deadlock between devlink lock and esw->wq
mlx5_eswitch_cleanup() calls destroy_workqueue() while holding the devlink lock through mlx5_uninit_one(). E-Switch workqueue workers also need the devlink lock, but previously took it before checking whether their work item was stale. This can deadlock when cleanup waits for a worker that is blocked on the same devlink lock. Mode changes have the same ordering hazard: the mode-change path holds devlink lock while tearing down the current mode, and old work may still be pending on the E-Switch workqueue. Fix this by making esw_wq_handler() check the generation counter before attempting to take devlink lock. The worker uses devl_trylock(); if the lock is busy and the work is still current, it sleeps on an E-Switch wait queue with a short timeout. Invalidation increments the generation counter and wakes the wait queue, so stale workers exit without spinning or blocking cleanup. Invalidate work at the earliest safe operation boundary. Cleanup invalidates before destroy_workqueue(), and QoS cleanup runs after the workqueue is destroyed. Mode teardown unregisters the work-producing notifiers first, then invalidates the queue before tearing down FDB/QoS/rate-node state. This prevents new notifier work from capturing the new generation while still making old work stale before expensive teardown starts. mlx5_devlink_eswitch_mode_set() now relies on mlx5_eswitch_disable_locked() for the mode-change invalidation instead of incrementing the generation after disable. mlx5_eswitch_disable() gets the same coverage. SR-IOV enable/disable paths invalidate before VF state changes so work against the old VF count or mode is discarded. Remove the conditional generation increment in mlx5_eswitch_event_handler_unregister(); mlx5_eswitch_disable_locked() now handles it unconditionally after the relevant notifiers are unregistered. Signed-off-by: Mark Bloch <mbloch@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260428051018.219093-4-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
Mark Bloch
|
2a110ee54e |
net/mlx5: E-Switch, introduce generic work queue dispatch helper
Each E-Switch work item requires the same boilerplate: acquire the devlink lock, check whether the work is stale, dispatch to the appropriate handler, and release the lock. Factor this out. Add a func callback to mlx5_host_work so the generic handler esw_wq_handler() can dispatch to the right function without duplicating locking logic. Introduce mlx5_esw_add_work() as the single enqueue point: it stamps the work item with the current generation counter and queues it onto the E-Switch work queue. Refactor esw_vfs_changed_event_handler() to match the new contract: it no longer receives work_gen or out as parameters. It queries mlx5_esw_query_functions() itself and owns the kvfree() of the result. The devlink lock is acquired and released by esw_wq_handler() before dispatching, so the handler runs with the lock already held. Update mlx5_esw_funcs_changed_handler() to use mlx5_esw_add_work(). Signed-off-by: Mark Bloch <mbloch@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260428051018.219093-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
Mark Bloch
|
f950ddb57c |
net/mlx5: E-Switch, move work queue generation counter
The generation counter in mlx5_esw_functions is used to detect stale work items on the E-Switch work queue. Move it from mlx5_esw_functions to the top-level mlx5_eswitch struct so it can guard all work types, not just function-change events. This is a mechanical refactor: no behavioral change. Signed-off-by: Mark Bloch <mbloch@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260428051018.219093-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
 Hamza Mahfooz
|
b31681206e |
hv_sock: fix ARM64 support
VMBUS ring buffers must be page aligned. Therefore, the current value of
24K presents a challenge on ARM64 kernels (with 64K pages). So, use
VMBUS_RING_SIZE() to ensure they are always aligned and large enough to
hold all of the relevant data.
Cc: stable@vger.kernel.org
Fixes:
|
||
 Maxime Chevallier
|
e2d217fe3f |
net: phy: aquantia: use ADVERTISE_XNP for extended next page advertising
When configuring the link parameters in forced mode for the AQR-105, the
Extended Next Page bit gets advertised for Multi-Gigabit modes.
This is done through bit 12 of MDIO_AN_ADVERTISE in MDIO_MMD_AN. This
contains a copy of the MII_ADVERTISE, for which 802.3 defines bit 12 as
the Extended Next Page advertising. This bit used to be marked as
reserved, but a proper define for it was added in :
commit
|