When a periodic output is initialized, its period and start time are
stored to initialize it back in case of restart. These information
aren't enough if the request contains flags or targets a pin that isn't
the first output of the switch. At restarts, these two arguments are
always set to 0.
The 'flag issue' isn't concrete so far because the driver doesn't
advertise any .supported_perout_flags so any flag request gets rejected
by the upper layer.
I don't know if other switches use non-zero indexes but the KSZ8463 has
twelve periodic outputs, so this index has to also be saved from now on.
Save the full request when a periodic output is successfully started.
Use the saved request when the periodic output is restarted.
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260925-ksz-perout-v4-1-d675bd21ce49@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
stmmac_tso_xmit() fills the MSS context descriptor and stores the new MSS
in tx_q->mss right away, but the descriptor only gets its OWN bit much
later, right before the frame is handed to the DMA. Every error path in
between - the dma_map_single() of the linear part and the
skb_frag_dma_map() of each fragment - returns with tx_q->mss already
updated while the MAC is still programmed with the previous MSS.
The context descriptor is now handled like the data descriptors are:
tx_q->cur_tx is not advanced while it is being filled, so the slot stays
where the next transmit fills it, and the error paths release it
explicitly instead of leaving a descriptor the DMA will stop on in the
middle of the ring. With the queue no longer wedged by that descriptor,
the stale cached MSS is what remains: the next skb carrying the same
gso_size compares equal to the cached value, no context descriptor is
emitted, and the hardware segments the TCP stream with the MSS of an
earlier frame, generating frames whose payload size does not match what
the stack accounted for.
Drop the cached value on those paths instead. Zero is what
stmmac_reset_tx_queue() leaves behind, so the next TSO frame programs the
context descriptor again.
The store itself stays ahead of the mappings, as before, rather than
moving next to the OWN bit: stmmac_tx_err() reinitialises the channel and
clears tx_q->mss from the DMA interrupt handler, which takes no TX queue
lock, so it can run in the middle of stmmac_tso_xmit(). Publishing the
cache after the descriptor has been handed over would widen the window in
which such a reset is overwritten with an MSS that the reinitialised
channel was never programmed with.
Found by manual code inspection and AI tools.
Not triggered or tested on real hardware.
Cc: stable+noautosel@kernel.org # untested fix to unlikely driver error path
Fixes: f748be531d ("stmmac: support new GMAC4")
Signed-off-by: Linkui Xiao <xiaolinkui@kylinos.cn>
Link: https://patch.msgid.link/20260928123422.1698785-1-xiaolinkui@126.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
smc_llc_link_active() marks a link active before scheduling its testlink
work. The first-link confirmation paths call it without llc_conf_mutex,
allowing link-down processing to clear the link between these operations:
Connection setup Link-down worker
smc_llc_link_active()
link->state = SMC_LNK_ACTIVE
smcr_link_clear()
link->clearing = 1
smc_llc_link_clear()
cancel_delayed_work_sync()
schedule_delayed_work()
The connection reference keeps the link alive during activation, but the
newly queued work outlives that reference. Later cleanup skips clearing
an already-clearing link, leaving its timer armed when the link group is
freed. KASAN reported:
BUG: KASAN: use-after-free in __run_timers+0x723/0x8d0
Write of size 8 at addr ffff88810f108810 by task swapper/1/0
Call Trace:
__run_timers+0x723/0x8d0
timer_expire_remote+0xd3/0x120
tmigr_handle_remote_up+0x4f4/0xab0
__walk_groups_from+0x40/0x150
tmigr_handle_remote+0x229/0x2c0
run_timer_softirq+0x1f5/0x250
Hold llc_conf_mutex around first-link activation on both sides so that
link-down processing cannot cancel the work before it is queued. Also
protect the client's initial optional add-link processing, which can
activate a second link without the lock. The other add-link paths already
hold llc_conf_mutex. This serializes every activation with link teardown
without changing the handshake sequence or error handling.
Signed-off-by: Chengfeng Ye <nicoyip.dev@gmail.com>
Link: https://patch.msgid.link/20260927074547.3694742-1-nicoyip.dev@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
__netpoll_send_skb() parks an skb on npinfo->txq whenever the device
cannot take it at once, and once the queue is non-empty every later skb
goes straight there to keep ordering. queue_process() drains it from a
workqueue and, unlike the direct path, never polls the device for
completions: when the ring is stopped it backs off HZ/10. Nothing limits
the queue length.
A producer that outruns that drain therefore grows the queue until the
host is out of memory. Observed with netconsole forwarding a GPU driver
that logged one line at ~1e5/s after a firmware hang. The NIC was
moving ~17k packets/s: completions for each burst surfaced tens of ms
later, outside the one-tick window, so queue_process() slept HZ/10 per
ring while ~1e5 lines/s kept arriving. The queue grew at ~170 MB/s,
unreclaimable slab reached 51 GiB in five minutes and the OOM killer
ran from kswapd with 341 MiB of anonymous memory on the whole box. What
the queue held was the flood itself; the OOM report never left the
host.
Reproduced on the same host (netconsole over a 10G ConnectX-4 Lx) under
the same slow-completion condition: 200k lines to /dev/kmsg in 0.12 s
grew unreclaimable slab by 173 MiB, about 188k skbs, draining at
~8-10k packets/s. With prompt completions the same burst drains at line
rate; a stall on the link while lines keep arriving faster than the
drain reproduces the growth.
Until the 2006 netpoll rework [1] the deferred path drained through
dev_queue_xmit(), with the stack's own backpressure, and was capped at
16 skbs (MAX_QUEUE_DEPTH). That series moved it to a direct
hard_start_xmit() with the HZ/10 back-off and made the queue
per-device, dropping the cap on the way.
Cap it at 1024 skbs per device and drop new skbs beyond that. The drop
is counted in tx_dropped of the device whose queue is full and freed
with SKB_DROP_REASON_FULL_RING. A netconsole target bound directly to
that device also gets NET_XMIT_DROP and, with CONFIG_NETCONSOLE_DYNAMIC,
counts it in xmit_drop_count. When a stacked device (bond, bridge,
team, vlan, macvlan) passes the skb down and the lower device's queue
is the one that fills, the return value does not reach netconsole and
the lower device's tx_dropped is the record. The bound holds either
way. Nothing is logged on the drop path because that would recurse
into the console being drained.
[1] https://lore.kernel.org/netdev/20061026225645.482978803@osdl.org/
Signed-off-by: Zack Gomez <zack.gomez@gmail.com>
Reviewed-by: Breno Leitao <leitao@debian.org>
Link: https://patch.msgid.link/20260925204537.2664119-1-zack.gomez@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
When retrieving the MAC address, ax88172a_bind() checks the return
value of asix_read_cmd() against ETH_ALEN to detect short reads.
Commit c28d9a2856 ("ax88172a: fix ax88172a_unbind() failures") added
an -EIO assignment to ensure that this failure path returns a negative
error code, even when asix_read_cmd() returns a non-negative short-read
length.
Short-read handling was subsequently added to asix_read_cmd() by commit
920a9fa27e ("net: asix: add proper error handling of usb read errors").
The helper now converts short reads to -ENODATA while preserving
negative errors from the underlying USB read operation.
The MAC address short-read check in ax88172a_bind() is therefore
redundant now, and overwriting the return value with -EIO is no longer
necessary to ensure that the failure path returns a negative error code.
Check only for negative return values and remove the -EIO assignment
to preserve the error returned by asix_read_cmd() through the existing
cleanup path.
Signed-off-by: Xinsheng Zhu <xinsheng.zhu.ny@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260928044011.63926-1-xinsheng.zhu.ny@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The L2 encapsulation modes of the seg6 lwtunnel reallocate the skb head
on every packet, where the IPv6 encapsulation modes reallocate only when
they have to. Ask for the whole encapsulation up front instead, so that
the reallocation happens at most once and only when the headroom really
is too small:
skb->mac_len + sizeof(struct ipv6hdr) + ipv6_optlen(tinfo->srh)
+ dst_dev_overhead(cache_dst, skb)
__seg6_do_srh_encap() then finds the room it needs and its own
skb_cow_head() becomes a no-op.
Drivers reserve more than that on the forwarding path, so the
reallocation usually disappears altogether. A single-segment policy
on ixgbe needs
14 (mac_len) + 40 (ipv6hdr) + 24 (SRH) + 16 (LL_RESERVED_SPACE) = 94
against the 206 bytes the driver leaves. Where the headroom is
smaller, as on a veth pair, pskb_expand_head() is called once per
forwarded packet instead of twice. Asking only for skb->mac_len would
still take two whenever the skb is header-cloned, because the cow that
unclones it does not also make room for the outer header.
The cost is amplified by CONFIG_INIT_ON_ALLOC_DEFAULT_ON, which many
distributions enable: every new head is zeroed in full, and that memset
alone accounts for 16% of the datapath profile.
Throughput at 0.5% packet loss, 64-byte frames forwarded through one
2.30 GHz core (Xeon E5-2650 v3, ixgbe 82599ES), offered by TRex and
binary-searched over 10 runs of 10 s:
Before: 654.6 kpps
After: 965.7 kpps
Signed-off-by: Yuya Kusakabe <yuya.kusakabe@gmail.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Link: https://patch.msgid.link/20260925-seg6-l2cow-v3-1-fc83821542a7@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
- ath10k: NVMEM device tree bindings
- ath12k: QMI firmware alignments
- mm81x: AP improvements
- mac80211:
- CIP (control frame integrity) support
- NAN improvements
- cfg80211:
- improvements for AP regulatory checks
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEpeA8sTs3M8SN2hR410qiO8sPaAAFAmq9A3UACgkQ10qiO8sP
aABm0g//QomwpMdiwQifQ7Im/a4BN/adDZ5u05oHs8wXIX9jVImgWVnrFFc9BjfH
+sqY8gAKIMJKsqguljqagcdvITBdJJKWkLf01uOwPR1uQPaFMOuzIJocoAJoSrnp
mIAoMxHuUZ2Aw9CE1NyrHo6FiRZF0o0vaIDfCRDBVC1qb1Z5HfGSLuSjuYC6z130
DhrZ0JAnhP3YPGv2qFMSbtmdzoML2R4KHpUg0Cp8slrahoGsFkTH4rvqyiGa5mXC
ICUwHmRgvr0a0cVUlGOEJh63ztgQxKTMUfP9THBPpL5R92YFrQRB90zE8NB7Kf0D
izZEYv++FVXR/lGnn1ka7SViOp9Sual/7v1lQRX+gr9VuXvspeUu0YnsEzbu8/QY
0QVrs7+o+2vJRH8muL/dqE0SBHQneM5nIXhDeAIIA+2kD+KpHocRrMUnxSiXWAFJ
/FjNkZfv0fHGAa4lYKq43Wisps3errKF2WuIKp+Wbv1Ej1czGsfb0b77ETEwZmNM
awvvbDbP+q/CmOtL6v4rOZ2K52pqaX2f2T55fLbjuM/P3hNjbxN5eTIaxrzfd/U0
ONrpo8tBFhe8NQDk8lobLwAAyW/kgiIbkf4eYsraLxK7ejJj6Kvr17fNjWLzxBok
71VQ7Mu6DVS0aN6J76AIRBRBMeDGyUF2zBVP8BCa3IuZxks4SyU=
=wiFU
-----END PGP SIGNATURE-----
Merge tag 'wireless-next-2026-09-30' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next
Johannes Berg says:
====================
More features:
- ath10k: NVMEM device tree bindings
- ath12k: QMI firmware alignments
- mm81x: AP improvements
- mac80211:
- CIP (control frame integrity) support
- NAN improvements
- cfg80211:
- improvements for AP regulatory checks
* tag 'wireless-next-2026-09-30' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (67 commits)
wifi: mac80211: Gracefully deauthenticate on association timeout
wifi: libertas: fix RX OOB access from device-controlled pkt_ptr
wifi: mwifiex: Reattach interfaces on suspend failure
wifi: b43legacy: work around stack frame size warning
wifi: cw1200: fix link_id_db OOB access via device-controlled link ID
wifi: mwifiex: bound SDIO fw dump count by memory table size
wifi: mac80211: start next ROC after purging an interface
wifi: mac80211: fix potential ack-skb leak on error path
wifi: mac80211: mesh: don't send peering close in listen
wifi: mac80211_hwsim: Support NAN deferred schedule completion
wifi: mac80211: Restrict probe request rates for minimal content
wifi: nl80211: allow a NAN peer schedule with 2 channels in the same slot
wifi: cfg80211: use sysfs_emit_at() in addresses_show
wifi: cfg80211: require zero terminator in valid_regdb country table
wifi: cfg80211: fix NAN local schedule update ordering and allocation
wifi: mac80211: Fix a race when expiring a mesh path
wifi: cfg80211: validate monitor channel set against radio usage
wifi: nl80211: reject color-change requests that change 6 GHz power type
wifi: nl80211: defer AP beacon regulatory check to start_ap
wifi: radiotap: add definitions for UHR U-SIG
...
====================
Link: https://patch.msgid.link/20260930124547.228697-29-johannes@sipsolutions.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Przemek Kitszel says:
====================
ice: fix stats array overflow via proper realloc
Fix OOB access to the stats arrays.
The first commit (new in v5) fixes stats code against VSI_CHNL case (ADQ).
Next three commits are simple refactors to make the rest smaller,
the fifth one untangles the logic/lifetime of the stats array entries,
then we have the final fix for OOB access to the stats array (combined
for both PF and VF VSIs.
====================
Link: https://patch.msgid.link/20260925132636.123300-1-przemyslaw.kitszel@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The ring stats arrays were sized in one place and indexed in another,
with nothing reconciling the two. ice_vsi_alloc_stat_arrays() gave up as
soon as a container existed:
if (pf->vsi_stats[vsi->idx])
/* realloc will happen in rebuild path */
return 0;
while ice_vsi_alloc_ring_stats() walks the arrays with
ice_for_each_alloc_txq() / ice_for_each_alloc_rxq(), that is, up to
vsi->alloc_txq / vsi->alloc_rxq. Whenever the arrays are shorter than
the count ice_vsi_set_num_qs() ends up computing, that loop reads and
stores past the end of the kmalloc'ed pointer arrays.
Deferring to "the rebuild path" does not hold. It cannot get the size
right, and some paths never call it at all.
ice_devlink_reinit_down() is one of the latter. It calls ice_vsi_decfg()
directly, which does not free pf->vsi_stats[], and nothing on the way
down releases the main VSI's entry either: ice_dealloc_vsis() runs only
from ice_init()/ice_deinit(), and the single entry that ice_unload()
does drop is the control VSI's, via ice_deinit_fdir(). The main VSI's
arrays therefore survive the reload, while ice_devlink_reinit_up() runs
ice_vsi_cfg() and recomputes the count from
netif_get_num_default_rss_queues(), which follows cpu_online_mask.
Sizing the arrays with most CPUs offline and then onlining them is
enough, no VF involved:
for c in /sys/devices/system/cpu/cpu[0-9]*/online; do echo 0 > $c; done
echo 0000:18:00.0 > /sys/bus/pci/drivers/ice/unbind
echo 0000:18:00.0 > /sys/bus/pci/drivers/ice/bind
for c in /sys/devices/system/cpu/cpu[0-9]*/online; do echo 1 > $c; done
devlink dev reload pci/0000:18:00.0 action driver_reinit
The unbind/bind is what makes the arrays actually be allocated at the
small size; a reload alone only reuses them.
The read then runs off the end of tx_ring_stats[] and picks up whatever
follows it in kmalloc-32. Here that was a string, 0x74756f5f6c697475
spelling "util_out" in memory order. It is stored into ring->ring_stats
and faults on the first dereference, in ice_setup_tx_ring(), call trace:
RIP: 0010:ice_setup_tx_ring+0x8d/0xe0 [ice]
ice_vsi_setup_tx_rings+0x2a/0x80 [ice]
ice_vsi_open+0x28/0x170 [ice]
ice_open_internal+0xc9/0x160 [ice]
__dev_open+0x138/0x2b0
__dev_change_flags+0x1d5/0x250
netif_change_flags+0x21/0x60
do_setlink.constprop.0+0x336/0xcf0
rtnl_newlink+0x4a4/0x9b0
Even where the rebuild path does run, it sizes the arrays before
ice_vsi_decfg() returns the queues to the PF pool, and for an
ICE_VSI_PF VSI with no explicit request it derives the count from that
shared pool. Nothing serializes it against the recount in
ice_vsi_set_num_qs(), so a concurrent release, say
"echo 0 > sriov_numvfs", leaves the final count larger than the arrays
that were already installed.
ice_vsi_alloc_stat_arrays() runs from ice_vsi_cfg_def(), right after
ice_vsi_alloc_def() called ice_vsi_set_num_qs(), so it is the first
place where the queue count is final. Make it the only authority: keep
the existing arrays when they are already long enough, and otherwise
grow them with ice_vsi_install_stat_arrays(), which carries the
surviving entries over. The check only forces a grow: while both arrays
are long enough they are kept, an oversized one being merely wasteful.
Once either is too short the whole container is replaced, and then the
other one follows the final count too, shrinking if that is what it
takes.
Michal Schmidt hit the same corruption through the VF path, where a
guest raises its queue count with VIRTCHNL_OP_REQUEST_QUEUES and the
following VF reset reconfigures the VSI with the larger count while the
old, shorter arrays are still installed:
BUG: KASAN: slab-out-of-bounds in ice_vsi_alloc_ring_stats+0x385/0x4a0 [ice]
Workqueue: ice ice_service_task [ice]
Call Trace:
kasan_report+0xd7/0x120
ice_vsi_alloc_ring_stats+0x385/0x4a0 [ice]
ice_vsi_cfg_def+0x12e2/0x2060 [ice]
ice_vsi_cfg+0xb5/0x3c0 [ice]
ice_reset_vf+0x858/0xf80 [ice]
ice_vc_request_qs_msg+0x1da/0x290 [ice]
ice_vc_process_vf_msg+0xb15/0x1430 [ice]
__ice_clean_ctrlq+0x70d/0x9d0 [ice]
ice_service_task+0x840/0xf20 [ice]
process_one_work+0x690/0xff0
worker_thread+0x4d9/0xd20
kthread+0x322/0x410
ret_from_fork+0x332/0x660
ret_from_fork_asm+0x1a/0x30
Allocated by task 2439:
kasan_save_stack+0x1c/0x40
kasan_save_track+0x10/0x30
__kasan_kmalloc+0x96/0xb0
__kmalloc_noprof+0x1d8/0x580
ice_vsi_cfg_def+0x115c/0x2060 [ice]
ice_vsi_cfg+0xb5/0x3c0 [ice]
ice_vsi_setup+0x180/0x320 [ice]
ice_start_vfs+0x1f3/0x590 [ice]
ice_ena_vfs+0x66d/0x798 [ice]
ice_sriov_configure.cold+0xe4/0x121 [ice]
sriov_numvfs_store+0x279/0x480
kernfs_fop_write_iter+0x331/0x4f0
vfs_write+0x4c4/0xe40
ksys_write+0x10c/0x240
do_syscall_64+0xd9/0x650
entry_SYSCALL_64_after_hwframe+0x76/0x7e
The buggy address belongs to the object at ffff88810affea40
which belongs to the cache kmalloc-32 of size 32
The buggy address is located 0 bytes to the right of
allocated 32-byte region [ffff88810affea40, ffff88810affea60)
Fixes: 288ecf491b ("ice: Accumulate ring statistics over reset")
Reported-by: Michal Schmidt <mschmidt@redhat.com>
Closes: https://redhat.atlassian.net/browse/RHEL-164321
Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Link: https://patch.msgid.link/20260925132636.123300-7-przemyslaw.kitszel@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
ice_vsi_realloc_stat_arrays() resized the ring stats arrays in place
with krealloc_array(), sizing them from vsi->req_txq/req_rxq. That is
not what ice_vsi_set_num_qs() computes later in ice_vsi_cfg_def(), so
after a rebuild the arrays could end up shorter than vsi->alloc_txq /
vsi->alloc_rxq, and ice_vsi_alloc_ring_stats() then walked past their
end.
The VF case shows the divergence. ice_sriov_set_msix_vec_count() writes
vsi->req_txq and then calls ice_vsi_rebuild(), so the old resizer sized
from req_txq, while ice_vsi_get_num_qs() reads vf->num_req_qs ?:
vf->num_vf_qs and ignores req_txq entirely. Once a guest has raised
vf->num_req_qs through VIRTCHNL_OP_REQUEST_QUEUES the two disagree and
the arrays come out shorter than the alloc_txq/alloc_rxq the rebuild
installs. The reset that such a request triggers is a different path,
ice_vf_reconfig_vsi(), which does not use this resizer at all; that one
is handled by the next patch.
Replace it with ice_vsi_resize_stat_arrays(), which allocates a fresh
struct ice_vsi_stats instead, sized with ice_vsi_get_num_qs() and the
queues ice_vsi_decfg() is about to return to the PF pool, which is
exactly what ice_vsi_set_num_qs() will compute once they are back
there, barring a concurrent change of the PF pool; the next patch stops
relying on that. Copy the surviving entry pointers over and install
the new structure, all before ice_vsi_decfg() runs. The entries that
did not fit are freed by ice_vsi_free_unused_stat_arrays(); the old
container itself then goes through __ice_vsi_free_stats() with
@free_entries set to false, since the entries it still points at now
belong to the new structure.
Allocating up front also means a failure no longer leaves a half-updated
ice_vsi_stats behind, with the Tx array already swapped and its surplus
Tx entries already freed, but the Rx allocation failed.
Put the allocate-install-free-surplus sequence in
ice_vsi_install_stat_arrays(), next to ice_vsi_new_stat_arrays(), so
that only the sizing decision is left in the resizer.
Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Link: https://patch.msgid.link/20260925132636.123300-6-przemyslaw.kitszel@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
ice_vsi_set_num_qs() mixed two things: deciding how many queues a VSI
gets, and applying all the side effects of that decision. Split the
decision out into ice_vsi_get_num_qs(), returning both counts at once.
To make that possible, group alloc_txq and alloc_rxq in struct ice_vsi
with struct_group_tagged(), which gives the return type without adding
any new storage. Field order changes slightly, num_txq now follows
alloc_rxq, but nothing depends on it.
ice_vsi_get_num_qs() takes @held_txq and @held_rxq from the start, even
though the only caller so far passes zero for both. They let a caller
ask what the counts would be once the queues the VSI currently owns are
back in the PF pool. A later commit adds the caller that needs this: the
rebuild path has to size its ring stats arrays before ice_vsi_decfg()
releases the queues, yet the arrays must match what ice_vsi_set_num_qs()
computes afterwards.
While reshaping the whole body, drop the kernel-doc line promising a
return value; ice_vsi_set_num_qs() returns void.
No functional change intended.
Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Link: https://patch.msgid.link/20260925132636.123300-5-przemyslaw.kitszel@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Split the allocation of a struct ice_vsi_stats and its two ring stats
arrays out of ice_vsi_alloc_stat_arrays(), which is left with just the
lookup and the store into pf->vsi_stats[].
The sole caller keeps passing the very same queue counts as before,
vsi->alloc_txq and vsi->alloc_rxq. A later commit adds a second caller
in the rebuild path, which cannot use vsi->alloc_* because it has to
size the arrays before the VSI is reconfigured.
Note that the error path no longer clears pf->vsi_stats[vsi->idx]; the
early return above guarantees it is already NULL.
No functional change intended.
Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Link: https://patch.msgid.link/20260925132636.123300-4-przemyslaw.kitszel@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Record the length of each ring stats array in struct ice_vsi_stats, so
that freeing the array entries no longer needs the owning VSI. Keep the
new fields in sync in both places that size the arrays.
With that, the body of ice_vsi_free_stats() becomes independent of the
VSI and can be split out as __ice_vsi_free_stats(). The @free_entries
parameter is always true here; a later commit adds a caller that frees
only the array container, after its entries have been handed over to a
freshly allocated stats structure.
The free path now stops at the recorded length instead of the VSI queue
count, so it follows the real allocation rather than a number that can
disagree with it. Sizing still does not: "ice: rebuild ring stats arrays
instead of reallocating them in place" starts using the lengths to carry
entries over, and only "ice: size ring stats arrays from the final queue
count" makes them authoritative for the allocation path.
Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Link: https://patch.msgid.link/20260925132636.123300-3-przemyslaw.kitszel@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
ice_vsi_alloc_stat_arrays() returns early for ICE_VSI_CHNL, so a channel
VSI never gets an entry in pf->vsi_stats[]. ice_vsi_realloc_stat_arrays()
dereferences that entry unconditionally, and ice_vsi_rebuild() calls it
before anything else, so the NULL is not filtered out anywhere.
The path is live. ice_prepare_for_reset() removes the queue channels only
for resets other than a PFR, so a PFR leaves the channel VSIs in place,
and ice_rebuild() then calls ice_rebuild_channels(), which rebuilds every
ICE_VSI_CHNL VSI it finds. A PF reset with ADQ (mqprio hardware offload)
configured thus dereferences NULL.
That combination is reset recovery on top of an active mqprio offload,
which is why it went unnoticed. It was found while refactoring this code,
not reported by a user.
I'm leaning towards removing our limited (compared to OOT ADQ) support,
but it's outside of this series. Bug could be triggered by:
tc qdisc del dev "$IF" root 2>/dev/null || true
tc qdisc add dev "$IF" root mqprio num_tc 2 \
map 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 \
queues 2@0 2@2 hw 1 mode channel
sleep 3
ethtool --reset "$IF" irq dma filter offload
Workqueue: ice ice_service_task [ice]
RIP: 0010:ice_vsi_rebuild+0x289/0x380 [ice]
ice_rebuild_channels+0xd6/0x320 [ice]
ice_rebuild+0x4f6/0x540 [ice]
ice_do_reset+0x9f/0x1a0 [ice]
ice_service_task+0x4a/0x460 [ice]
Fixes: 5995ef88e3 ("ice: realloc VSI stats arrays")
Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Link: https://patch.msgid.link/20260925132636.123300-2-przemyslaw.kitszel@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
When tcp_collapse() rebuilds skbs under memory pressure, the copy
process doesn't include the right tstamp and hwtstamp from the
old skb. And memcpy(nskb->cb, skb->cb, ...) copies has_rxtstamp,
but nskb->tstamp and hwtstamps are left at zero, so
tcp_recv_timestamp() ends up emitting no cmsg at all.
In net timestamping case, if such an skb happens to be the last
one consumed in a recvmsg() call, the application receives no RX
timestamp for that call.
Fix this by copying both tstamp and hwtstamp of the last skb to
the new skb, matching tcp_try_coalesce()/tcp_add_backlog().
Note that the has_rxtstamp flag can still be inherited through
the cb memcpy from an skb that contributes no bytes (fully covered
skb left in the ofo tree by the tcp_ooo_try_coalesce() ->
coalesce_done path), so set TCP_SKB_CB(nskb)->has_rxtstamp to false
which makes the new block the only place setting it.
Signed-off-by: Jason Xing <kerneljasonxing@gmail.com>
Reviewed-by: Eric Dumazet <edumazet@kernel.org>
Link: https://patch.msgid.link/20260924152529.5689-1-kerneljasonxing@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Matthieu Baerts says:
====================
mptcp: misc improvements for v7.4
Here are some unrelated improvements for MPTCP:
- Patch 1: reduce struct mptcp_subflow_context size: no need to store
the truncated HMAC for the whole connection.
- Patches 2-3: shrink struct mptcp_options_received used to parse
incoming MPTCP options, from 136 to 72 bytes on x86_64.
====================
Link: https://patch.msgid.link/20260926-net-next-mptcp-misc-feat-7-4-v1-0-67af4ab37406@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
struct mptcp_options_received is allocated on the stack while parsing
incoming MPTCP options. Several suboptions are mutually exclusive, as
enforced by mptcp_parse_option(), so their payloads can overlap.
Group fields by suboption and place the mutually exclusive payloads in
an anonymous union. Keep DSS and rm_list outside the union: they can
be combined with other suboptions. Move join_id into the MP_JOIN
group, and overlap token, thmac and hmac inside that group.
Further shrinking would require changing the parser so currently
coexisting fields (DSS mapping vs ACK, rm_list, status flags) can
overlap. That adds complexity for little gain, since the outer union is
already dominated by the MP_JOIN / ADD_ADDR members.
This reduces the structure size from 136 to 72 bytes on x86_64.
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/625
Signed-off-by: Quanye Yang <quanyeyang@proton.me>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260926-net-next-mptcp-misc-feat-7-4-v1-3-67af4ab37406@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
MP_CAPABLE and MP_FASTCLOSE both stored their key in rcvr_key. Give
FASTCLOSE a dedicated fc_recv_key overlapped with rcvr_key in a union.
This helps shrink struct mptcp_options_received.
Signed-off-by: Quanye Yang <quanyeyang@proton.me>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260926-net-next-mptcp-misc-feat-7-4-v1-2-67af4ab37406@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This entry is only used in subflow_finish_connect().
Instead, use the original value from mp_opt, and pass it to
subflow_thmac_valid() to do the validation with the given truncated
hmac.
While at it, rename the variables in subflow_thmac_valid() to avoid
confusions about the received one vs the expected one.
Reviewed-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260926-net-next-mptcp-misc-feat-7-4-v1-1-67af4ab37406@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
octeontx2 has a bunch of symbols not used outside the module which
defines them. Worse, still the macro which defines otx2_mbox_up_handler_*
adds exports for all the functions. Remove all the explicit exports
and the auto-export from that macro.
otx2_mbox_up_handler_cgx_link_event was exported by the macro and
is genuienly called from the VF driver, so add an export.
Link: https://lore.kernel.org/arYYTw8l90VNnKal@infradead.org
Reviewed-by: Christoph Hellwig <hch@lst.de>
Link: https://patch.msgid.link/20260925201042.1174488-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The current eMDIO MDC rate is 558 kHz on i.MX95 B0. This is very low,
but also very compatible. However, for example NXP TJA1120 PHY needs
at minimum 1 MHz MDC clock and 558 kHz does not work with that PHY.
As a minimum change, increase the MDC clock to 2.5 MHz which matches
the 802.3 specification. Also, even old PHYs like LAN8210Ai, KSZ8794,
DP83822 support up to 2.5 MHz MDC clock frequency, and it covers the
NXP TJA1120 as well. There is no known rationale for why the 558 kHz
was picked when the eMDIO driver was added.
Signed-off-by: Marek Vasut <marex@nabladev.com>
Link: https://patch.msgid.link/20260924180607.60932-1-marex@nabladev.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Théo Lebrun says:
====================
net: macb: fix close races (and RX refill error handling)
The context-swapping series [0] has been ongoing for a while. The most
interesting part is a proper hardware shutdown sequence, which is truly
lacking in other parts of the MACB driver: at close, at suspend and in
the HRESP error task.
Instead of introducing that sequence for a new feature, apply it now to
fix the main offender, the close path. That fixes the races listed in
patch 3 and will allow the sequence to be reused later.
The first two patches are also fixes, but not related to the shutdown
sequence: they address allocation-failure codepaths. They are sent
alongside patch 3 because they touch the same code and would cause
merge conflicts if applied separately.
Now, let me list issues I'm aware of that we do *not* fix here, to make
the scope explicit:
- HRESP task should sync with all other contexts. It frees buffers
under the feet of the whole driver. The hardware shutdown sequence
will help.
- Suspend callback is also racy with BH primitives. We'll be able to
reuse the hardware shutdown sequence.
- Even if we assume tasks are frozen, the phylink ops aren't and might
trigger between suspend and resume callbacks. Here we need to
(1) early return in phylink ops and (2) at resume put the HW in its
proper state according to phylink ops that occured.
- Alloc failure codepaths aren't perfect outside open. Hardware and
ring buffers are left in a sad state. We can probably do better.
[0]: https://lore.kernel.org/all/20260812-macb-context-v9-0-7ddbf5f715e0@bootlin.com/
====================
Link: https://patch.msgid.link/20260925-macb-close-v2-0-360efa565914@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The macb_close() operation is facing races as it disables IRQs late in
its sequence and keeps BH primitives alive while shutdown.
Non exhaustive list of races that could occur:
- macb_tx_error_task() could be scheduled and access the buffers freed
by macb_close().
- macb_tx_error_task() or macb_hresp_error_task() might re-enable
interrupts after the IDR write in macb_close().
- macb_close() calls napi_disable() meaning that if
macb_tx_error_task() occurs later, it will deadlock on napi_disable()
that shouldn't be called if NAPI is already disabled.
- macb_hresp_error_task() might reinit every RX/TX ring under
macb_close()'s foot.
- macb_interrupt() might re-enable NAPI just after it has been
disabled by macb_close().
Instead, disable all our primitives one by one:
- (1) mask and sync on IRQ handlers,
- (2) drain any scheduled bp->hresp_err_bh_work,
- (3) drain any scheduled queue->tx_error_task,
- (4) drain queue->napi_rx/napi_tx,
- (5) drain bp->tx_lpi_work.
Careful! Ordering is important because our scheduling primitives can
wake each other up. Recap table:
| | enable/disable | schedule |
| |----|-------|-------|------|----|----|--------|-----|
| |IRQs|napi_tx|napi_rx|tx_lpi|napi|napi|tx_error|hresp|
| Context | | | | task | rx | tx | task |task |
|===============|====|=======|=======|======|====|====|========|=====|
| open | X | X | X | | | | | |
| link_up | X | | | | | | | |
| link_down | X | | | | | | | |
| close | X | X | X | | | | | |
| enable_tx_lpi | | | | X | | | | |
| swap | X | X | X | X | | | | |
| suspend | X | X | X | | | | | |
| resume | X | X | X | | | | | |
|---------------|----|-------|-------|------|----|----|--------|-----|
| irq & netpoll | X | | | | X | X | X | X |
|---------------|----|-------|-------|------|----|----|--------|-----|
| napi_rx | X | | | | X | | | |
| napi_tx | X | | | X | | X | | |
|---------------|----|-------|-------|------|----|----|--------|-----|
| tx_error_task | X | X | | | | | | |
| hresp task | X | | | | | | | |
As example, one ordering constraint that can be deduced from the table:
napi_tx can schedule tx_lpi_task meaning napi_tx must be disabled
before tx_lpi_task, else we risk napi_tx re-enabling tx_lpi_task after
it has been disabled by macb_close().
We do *not* use IDR masking to shutdown IRQs because that risks
conflicting with BH primitives we have not disabled yet. For example if
we writel(IDR) in macb_close() and napi_rx is pending then IRQs might
be unmasked by the NAPI poll. As for why we do not use disable_irq():
we will have situations where we are quiesced but want to listen to
some IRQs and (minor reason) we register shared IRQ handlers so we
shouldn't disable the full IRQ line.
Instead we introduce a bool that tells macb_interrupt() to self-disarm.
Its default value is true as we start closed. It gets set to false
while interface is active. Reading into my crystal ball, we'll reuse
that flag in suspend/WOL, set_ringparam and change_mtu (context swap).
Note that old IRQ handler tried preventing a race with close by
self-disarming based on netif_running(). This might work, but it does
not prevent a race with the error codepath of macb_open() which needs
to run with IRQs dis-armed but netif_running() returns true during that
time.
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Link: https://patch.msgid.link/20260925-macb-close-v2-3-360efa565914@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
gem_rx_refill() is responsible for Rx SKB allocation, including at open,
but its prototype indicates a void return value.
Therefore we change the code to propagate allocation and DMA mapping
errors back up the stack, making sure the open fails if no descriptors
were allocated. Change all those to return errno-style ints:
- gem_rx_refill()
- its parent gem_init_rx_ring()
- its grand-parent gem_init_rings()
- the macbgem_ops.mog_init_rings function pointer
- its grand-uncle macb_init_rings()
We tolerate some allocation failures: we accept running with the rx ring
only partially filled with successful descriptors. It is important we
refuse the zero-valid-descriptor case: nothing would ever trigger a
refill, which only happens once a frame has been received.
Theoretical bugfix, never encountered in practice. To reproduce,
introduce memory pressure (less than 512 SKBs of free memory) and open
the interface. I expect the last queue to be unusable because it has
zero usable rx buffers.
Note that other callers of refill (resume, HRESP error task, NAPI)
cannot do anything useful with that error and keep their best-effort
refill, hoping it will improve.
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Link: https://patch.msgid.link/20260925-macb-close-v2-2-360efa565914@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The refill logic is simple: iterate over all pending rx slots, allocate
SKB (& DMA map) if needed and hand it off to the hardware by clearing
the RX_USED flag.
If the refill operation fails mid-way, it early returns leaving the
remaining slots untouched. In an initialised ring that is safe: a slot
is either owned by the hardware holding a valid buffer, or
software-owned (RX_USED set) waiting for refill to hand it a new one.
When slots have never been initialised however, we are in trouble.
After dma_alloc_coherent() of the rx ring buffer, all slots have NULL
pointers and RX_USED cleared meaning HW will try using them. Ensure
this does not happen by setting the RX_USED flag on all slots before
calling refill at buffer alloc, in gem_init_rx_ring(). That way even if
refill fails on an alloc/dma_map, the HW won't try using NULL pointers
as buffers.
Note we tweak gem_rx() and macb_rx_pending(): their previous stop
condition was only if desc was RX_USED. Now it must be either RX_USED
or we got out of the range of successfully allocated descriptors
(detected using the rx_tail and rx_prepared_head cursors).
Otherwise gem_rx() could consume unallocated buffers.
Theoretical bugfix, never encountered in practice. To reproduce,
introduce memory pressure (less than 512 SKBs of free memory) and open
the interface.
Note that this codepath also hits at resume, on HRESP errors and on
set_ringparam (while interface is running).
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Link: https://patch.msgid.link/20260925-macb-close-v2-1-360efa565914@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
James Hilliard says:
====================
net: stmmac: add Allwinner H616 EMAC1 support
The H616 secondary EMAC supports RMII at 10/100 Mbps and uses a separate
system-control clock register at offset 0x34. Add its binding and a
sun8i stmmac variant using that register. A distinct compatible without
an older fallback prevents the driver from using EMAC0's clock register.
EMAC1 connects internally to the co-packaged AC200 or AC300 EPHY and has
no external PHY pins. Leave PHY initialization to the PHY driver instead
of using the H3 internal-PHY controls. The RMII-only variant does not
expose the RGMII clock-delay properties.
First move the MAC software reset from probe to the DMA reset callback,
after PHY initialization. This lets the MAC and its MDIO bus remain
registered when the PHY driver or one of its suppliers is not ready yet.
Mask interrupts before requesting reset and clear DMA and interrupt state
even if it times out. Keep the separate H3 MDIO-mux reset sequence
unchanged.
The AC200/AC300 EPHY driver and package bindings are already in
net-next. This series separates the H616 EMAC1 MAC driver and binding
support from the earlier combined series. PWM, MFD and device-tree
enablement are being handled separately.
====================
Link: https://patch.msgid.link/20260927-submit-h616-emac1-v1-v6-0-e64971f4e414@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The H616 secondary EMAC uses a separate system-control clock register
and supports only RMII at 10/100 Mbps. It connects internally to the
co-packaged AC200 or AC300 EPHY and has no external PHY pins.
Add an EMAC1 variant using the dedicated register and enable only RMII.
Leave PHY initialization to the PHY driver instead of using the H3
internal-PHY controls. No RX or TX clock delays are configured for this
RMII-only variant.
Co-developed-by: Richard Genoud <richard.genoud@bootlin.com>
Signed-off-by: Richard Genoud <richard.genoud@bootlin.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Alastair D'Silva <alastair@d-silva.org>
Tested-by: Alastair D'Silva <alastair@d-silva.org>
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Link: https://patch.msgid.link/20260927-submit-h616-emac1-v1-v6-3-e64971f4e414@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The H616 secondary EMAC uses a separate system-control clock register
and supports only RMII at 10/100 Mbps. Add its distinct compatible
without an older fallback, since using the primary EMAC clock register
would not work.
Constrain the PHY interface mode to RMII, matching the hardware.
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Link: https://patch.msgid.link/20260927-submit-h616-emac1-v1-v6-2-e64971f4e414@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The MAC software reset needs a running receive clock from the PHY.
Resetting the MAC at the end of probe therefore fails when the PHY driver
has not been loaded or its probe has deferred on a missing supplier. The
failure removes the MAC and its MDIO bus, so loading the missing driver
later cannot recover the interface without reprobing the MAC.
Perform the software reset in the DMA reset callback instead. The stmmac
core calls it during hardware setup after attaching and initializing the
PHY, and resumes a suspended PHY before reopening or resuming the MAC.
Mask interrupts before requesting the reset and retain the existing
DMA and interrupt-register clearing even if the reset times out. Return
reset errors through the normal hardware-setup error path.
Remove the unconditional reset from probe. Keep the separate H3 MDIO-mux
reset after switching the mux and powering the selected PHY, since it is
needed to latch the selected interface before MDIO accesses.
Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Link: https://patch.msgid.link/20260927-submit-h616-emac1-v1-v6-1-e64971f4e414@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Smatch combines the return values together and wants all the callers
to handle the positive values so it leads to static checker warnings.
Add a comment explaining the return values.
Generally functions which return non-standard values should have a
comment.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Link: https://patch.msgid.link/09f24cefc214455305543a0528ceae6349c77419.1790357822.git.error27@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Lawrence Lee says:
====================
ipv6: update NUD_FAILED neighbors from NA messages
Neighbor Advertisements for existing NUD_FAILED entries are currently
ignored. This can leave a first-hop router with an unusable neighbor after
the host becomes reachable and announces itself, particularly when
forwarding is offloaded away from the kernel and traffic destined to the
FAILED neighbor is unable to trigger the kernel's normal neighbor
resolution process.
Allowing neighbor entries to be updated from NAs already received by the
kernel is preferable since it creates less work compared to periodically
probing FAILED neighbors (e.g. using NTF_EXT_MANAGED).
Extend accept_untracked_na to treat FAILED entries like absent entries.
Require a target link-layer address, IPv6 forwarding, and acceptance by the
sysctl, including its source-prefix check in mode 2. Recover the entry only
to STALE, including for solicited NAs, to maintain parity with handling of
non-existent neighbor cache entries.
Patch #1 implements the behavior and updates RFC 9131-related comments and
accept_untracked_na documentation.
Patch #2 extends ndisc_unsolicited_na_test.sh to cover FAILED-entry
recovery and each acceptance gate, including in-prefix and out-of-prefix
mode 2.
Thanks to Ido Schimmel for feedback on the original RFC.
====================
Link: https://patch.msgid.link/cover.1790127207.git.lfqlee314@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Seed a FAILED neighbor before triggering an unsolicited NA. Verify that
the entry transitions to STALE and learns the advertised link-layer
address only when drop_unsolicited_na is disabled, accept_untracked_na
mode 1 or in-prefix mode 2 is enabled, and IPv6 forwarding is enabled.
Verify that disabling each gate keeps the entry in FAILED without a
link-layer address.
Mark the seed externally learned and disable carrier-based eviction so
the entry cannot be garbage-collected before the NA arrives. Require the
marker after processing to prove that a recovered entry was updated in
place instead of deleted and recreated.
Keep the NA source, target, and neighbor key fixed for the mode 2 cases.
Vary the prefix configured on the router to exercise the source-prefix
check without changing the entry under test.
Arm packet capture before bringing up the host interface and starting
DAD. Wait for the capture to become ready and for tcpdump to exit so the
NA cannot be missed and receive processing is complete before checking
the neighbor entry.
Preserve the return code from test_unsolicited_na_common() before
constructing the test description. The array assignment previously reset
the return code to zero and caused existing cases to report false success.
Link: https://lore.kernel.org/r/20260813233344.445265-1-lfqlee314@gmail.com
Signed-off-by: Lawrence Lee <lfqlee314@gmail.com>
Link: https://patch.msgid.link/ce40008682ed26ab039168a5fcb515eff8d30c3a.1790127207.git.lfqlee314@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Transition a FAILED neighbor entry to STALE upon receipt of an NA
message on routers when accept_untracked_na is enabled. This extends the
RFC 9131 accept_untracked_na behavior so that FAILED entries are treated
the same as non-existent entries.
RFC 4861 section 7.3.3 says that an entry should be deleted when address
resolution fails. Linux instead retains the entry in NUD_FAILED, so
treating it as untracked is consistent with the protocol model.
Trying to resolve FAILED neighbors via periodic probing (e.g. using
NTF_EXT_MANAGED) is more work compared to this approach which uses
information in NAs that the kernel may already be receiving. Note that
because this behavior in IPv6 is dependent on the accept_untracked_na
sysctl setting, this approach is more conservative than IPv4 which
transitions FAILED neighbors to STALE by default upon receiving GARPs.
Link: https://lore.kernel.org/r/20260813233344.445265-1-lfqlee314@gmail.com
Signed-off-by: Lawrence Lee <lfqlee314@gmail.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/6be400e601f4ffa59e47ddb5daa33ecdd85dd88b.1790127207.git.lfqlee314@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Arthur Crepin Leblond says:
====================
w5100: restore GPIO-based link detection
In the previous version of the w5100 driver, the LINKLED pin could be
wired to a GPIO to detect the link status changes via an interrupt.
This only works on w5500 as it is the only one documenting its LINKLED
pin to hold the link status (on w5100 the LINKLED pin is changing with
RX/TX activity).
This series of patches is bringing back the link status detection on
w5500 using the Link Status bit of the PHY Configuration Register.
Additionally, the LINKLED pin can also be wired to detect link status
changes and read the register in the interrupt handler.
====================
Link: https://patch.msgid.link/20260924-wiznet-link-gpio-v11-0-42a332517b30@marmottus.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Detect the carrier state on the w5500 Ethernet controller using the
Link Status bit from the PHY Configuration register (PHYCFGR).
On w5100/w5200, which lack this register, get_link() is not implemented
and the carrier state is not reported (netif_carrier_(on|off) is not
called).
For the w5500, add an optional interrupt, wired to the LINKLED pin of
the device, to detect link status changes with a read of the PHYCFGR
register and update of the carrier state with netif_carrier_(on|off).
If this interrupt is not set in the DT binding, get_link() is not
implemented and the carrier state is not reported
(netif_carrier_(on|off) is not called).
The interrupt handler and the PHYCFGR register readings are
synchronized using a mutex.
A few changes are also brought for the bring-up/teardown
synchronization:
- The net device is registered last in the probe() function so no
operation can be performed before the probing is finished
- The net device is unregistered first in remove()
- dev_name is now used instead of netdev_name
- w5100_stop() calls cancel_work_sync() and flush_work() to make sure
there is no race condition or unfinished work
- w5100_suspend() calls w5100_stop()
- w5100_resume() calls w5100_open()
- The main irq is not automatically enabled in w5100_probe() but in
w5100_open() and disabled in w5100_stop()
Commit dacf281771 ("w5100: remove unused gpio link detection")
dropped the link_gpio/link_irq handling on the grounds that no
devicetree user passed a "link" gpio at the time and that it used the
old gpio interface.
This isn't a plain revert of that removal: link detection is now done
using a second interrupt rather than a gpio with a documented DT
binding.
Set the WIZNET entry as DRIVER and add drivers/net/ethernet/wiznet in
MAINTAINERS file.
Signed-off-by: Arthur Crepin Leblond <arthur@marmottus.net>
Fixes: dacf281771 ("w5100: remove unused gpio link detection")
Link: https://patch.msgid.link/20260924-wiznet-link-gpio-v11-3-42a332517b30@marmottus.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add an optional link status interrupt which can be connected to the
LINKLED pin on the device to detect link status changes. This second
interrupt is only supported on wiznet,w5500.
Signed-off-by: Arthur Crepin Leblond <arthur@marmottus.net>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20260924-wiznet-link-gpio-v11-2-42a332517b30@marmottus.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Convert the Wiznet w5x00 SPI Ethernet controller binding from
plain text to DT schema.
Change the trigger type from edge-falling to low to match the driver
implementation.
Add wiznet,w5100.yaml entry in MAINTAINERS.
Signed-off-by: Arthur Crepin Leblond <arthur@marmottus.net>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260924-wiznet-link-gpio-v11-1-42a332517b30@marmottus.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
After reclaiming, the Tx poll asks to be polled again. That extra poll
finds nothing to do and does not reduce the interrupt rate.
Complete the NAPI and unmask the ring interrupt right after the reclaim.
On a CM4 this raises 60 byte pktgen Tx from about 187k to 224k pps and
saves about 5% of one core at TCP line rate.
Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260928121454.901306-1-nb@tipi-net.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Replace if/else blocks using regmap_set_bits()/regmap_clear_bits() with
the simpler regmap_assign_bits() calls in the lantiq gswip, mt7530 and
qca8k drivers.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Link: https://patch.msgid.link/20260924083538.461887-1-peng.fan@oss.nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Use IP_LOCAL_PORT_RANGE to limit a socket to 8 ports, bind 8 sockets
to port 0 and check they get 8 distinct ports and the 9th bind fails
with EADDRINUSE. Run it for the four combinations of reuse options on
the sockets:
none (existing test)
SO_REUSEPORT
SO_REUSEADDR
SO_REUSEADDR + SO_REUSEPORT
TCP passes all four. Before the udp fix UDP only passes the first
one: the scan hands out a port already taken by a socket with the
same reuse options, so fewer than 8 distinct ports come back and the
9th bind succeeds.
# ./ip_local_port_range.sh
Before:
ok 13 ip_local_port_range.ip4_udp.exhaust_8_port_range
not ok 14 ip_local_port_range.ip4_udp.exhaust_8_port_range_reuseport
not ok 15 ip_local_port_range.ip4_udp.exhaust_8_port_range_reuseaddr
not ok 16 ip_local_port_range.ip4_udp.exhaust_8_port_range_reuseaddr_reuseport
ok 49 ip_local_port_range.ip6_udp.exhaust_8_port_range
not ok 50 ip_local_port_range.ip6_udp.exhaust_8_port_range_reuseport
not ok 51 ip_local_port_range.ip6_udp.exhaust_8_port_range_reuseaddr
not ok 52 ip_local_port_range.ip6_udp.exhaust_8_port_range_reuseaddr_reuseport
After:
ok 13 ip_local_port_range.ip4_udp.exhaust_8_port_range
ok 14 ip_local_port_range.ip4_udp.exhaust_8_port_range_reuseport
ok 15 ip_local_port_range.ip4_udp.exhaust_8_port_range_reuseaddr
ok 16 ip_local_port_range.ip4_udp.exhaust_8_port_range_reuseaddr_reuseport
ok 49 ip_local_port_range.ip6_udp.exhaust_8_port_range
ok 50 ip_local_port_range.ip6_udp.exhaust_8_port_range_reuseport
ok 51 ip_local_port_range.ip6_udp.exhaust_8_port_range_reuseaddr
ok 52 ip_local_port_range.ip6_udp.exhaust_8_port_range_reuseaddr_reuseport
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Link: https://patch.msgid.link/20260928023145.301855-2-jiayuan.chen@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Observed with two independent servers in the same process:
fd1 = socket(AF_INET, SOCK_DGRAM, 0);
setsockopt(fd1, SOL_SOCKET, SO_REUSEPORT, ...);
bind(fd1, port 0); /* got 40000 */
fd2 = socket(AF_INET, SOCK_DGRAM, 0);
setsockopt(fd2, SOL_SOCKET, SO_REUSEPORT, ...);
bind(fd2, port 0); /* got 40000 as well */
Both sockets end up on the same port and join the same reuseport
group, so each of them takes part of the other's datagrams. The same
port sharing happens with SO_REUSEADDR, without the reuseport group.
udp_lib_lport_inuse() keeps the reuse rules when it scans for a free
port: a socket with SO_REUSEADDR set, or one with SO_REUSEPORT and
the same uid, is not a conflict, so its port is never marked in the
bitmap and the scan can hand it out again. Those rules only make
sense when the user asks for a specific port. bind(0) wants a free
port and has no way to know whose port it lands on.
TCP already does this: inet_csk_find_open_port() passes relax=false
and reuseport_ok=false, so the scan treats every port in use as a
conflict whatever options the sockets have. Commit aacd9289af
("tcp: bind() use stronger condition for bind_conflict") did it for
SO_REUSEADDR and commit 0643ee4fd1 ("inet: Fix get port to handle
zero port number with soreuseport set") for SO_REUSEPORT.
Do the same for UDP: ignore both options during a scan, keep them
for an explicit port.
This changes bind(0) for SO_REUSEADDR sockets once the port range is
full: it used to share a port and now fails with EADDRINUSE, like
TCP. Sharing a port on purpose when the range is full is a feature,
TCP has net.ipv4.ip_autobind_reuse for it, off by default. UDP can
get the same knob later, this patch only fixes the scan.
Fixes: ba418fa357 ("soreuseport: UDP/IPv4 implementation")
Cc: stable+noautosel@kernel.org # bind() behaviour change
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Link: https://patch.msgid.link/20260928023145.301855-1-jiayuan.chen@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
When disconnecting a device while firmware is not present on the system,
usbatm_usb_disconnect() waits for the heavy_init thread to finish:
wait_for_completion(&instance->thread_exited);
If CONFIG_FW_LOADER_USER_HELPER_FALLBACK is enabled, missing firmware
causes request_firmware() to fall back to sysfs/udevd. This creates a
circular dependency during disconnect:
1. usb_disconnect() holds device_lock(&udev->dev).
2. usbatm_usb_disconnect() waits for instance->thread to exit.
3. instance->thread waits for request_firmware() sysfs fallback.
4. udevd receives the firmware uevent and attempts to read sysfs
attributes (e.g. serial), blocking on device_lock(&udev->dev).
Furthermore, the fallback wait uses wait_for_completion_killable_timeout(),
which ignores the non-fatal SIGTERM signal sent by usbatm_usb_disconnect().
Because speedtch and cxacru probe multiple candidate firmware files
sequentially, each file stalls for the 60-second fallback timeout,
triggering hung task timeouts (>120s) reported by syzbot.
Switch to request_firmware_direct() to probe firmware files directly from
the filesystem without falling back to user-mode helper.
Cc: stable+noautosel@kernel.org # untested fix to a driver init path race
Reported-by: syzbot+9ca2c9f85bd8b5e46516@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=9ca2c9f85bd8b5e46516
Signed-off-by: Matvey Valigura <valigurasm@gmail.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260924050654.15347-1-valigurasm@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Stanislav Fomichev says:
====================
net: consolidate devmem net_iov freelist and DMA handling
Follow up on the recently merged devmem gen_pool removal by consolidating
devmem's net_iov freelist and DMA-address handling.
- move devmem freelist to index-based approach with push/pop helpers
- switch devmem to public memory-provider helpers and reject DMA
addresses that cannot be represented
- decode stored DMA addresses for TX on 32-bit systems with 64-bit
dma_addr_t
====================
Link: https://patch.msgid.link/20260925201522.254717-1-sdf@fomichev.me
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
On 32-bit architectures where dma_addr_t is wider than unsigned long,
page_pool_set_dma_addr_netmem() stores page-aligned DMA addresses shifted
by PAGE_SHIFT. The net_iov branch of __skb_frag_dma_map() adds byte offsets
to the encoded value, so the NIC is programmed with an invalid DMA address.
This can trigger an IOMMU fault or DMA from unintended memory.
Consolidate DMA address encoding, decoding, and representability checks in
netmem helpers. Use the common decoder from the page pool and net_iov TX
paths so both interpret stored addresses consistently.
Reviewed-by: Mina Almasry <almasrymina@google.com>
Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/20260925201522.254717-4-sdf@fomichev.me
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Use public memory-provider helpers for DMA address storage and page-pool
association instead of open-coding page_pool state and accounting.
Zero the net_iov array because net_mp_niov_set_page_pool() ORs
PP_SIGNATURE into pp_magic. Reject DMA addresses that cannot be
represented in net_iov metadata.
Reviewed-by: Mina Almasry <almasrymina@google.com>
Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/20260925201522.254717-3-sdf@fomichev.me
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Move devmem's freelist to an index-based approach similar to io_uring.
This halves the memory requirements for the freelist.
Reviewed-by: Mina Almasry <almasrymina@google.com>
Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/20260925201522.254717-2-sdf@fomichev.me
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The Marvell PHY driver consumes marvell,reg-init as one or more
<page register mask value> tuples. Define the property so dtbs_check
validates the existing board descriptions.
Existing users have no compatible or just "ethernet-phy-ieee802.3-c22"
so this has to go into the generic ethernet-phy.yaml schema. Marking it
deprecated both for that reason and because opaque register
initialization values are discouraged in DT.
Assisted-by: LLM
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260925140410.1157036-2-robh@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
sock_sendmsg_nosec() runs in syscall context but calls BUG_ON() if
proto_ops->sendmsg() returns -EIOCBQUEUED. Crashing the kernel on an
unexpected return value is dangerous for production workloads.
This risk is real: any signed integer overflow in a sendmsg handler
that returns 0xfffffdef (-529, -EIOCBQUEUED) triggers this BUG_ON. In
one month, two such bugs were reported in PF_PACKET, reachable by
a local user with CAP_NET_RAW in a user namespace:
- Commit 73e594c19b ("af_packet: Don't cast tpacket_hdr.tp_len to int
in tpacket_parse_header().")
- In review ("net/packet: prevent TX_RING byte count overflow")
https://lore.kernel.org/netdev/20260925124829.6595-1-ilkka.lappetelainen@gmail.com/
Replace the BUG_ON with DEBUG_NET_WARN_ON_ONCE() to retain debug and
syzbot coverage, and return -EIO so that -EIOCBQUEUED does not leak to
userspace or trigger the BUG_ON(ret == -EIOCBQUEUED) in VFS callers of
sock_write_iter() such as new_sync_write().
Failing gracefully is safe because the original reason for the BUG_ON
is gone. It was added in commit 599bd19bdc ("fs: don't allow to complete
sync iocbs through aio_complete") and commit d8725c86ae ("get rid of the
size argument of sock_sendmsg()") to prevent an async completion from
corrupting a caller's on-stack kiocb. Commit 1b78414047 ("net: Remove
iocb argument from sendmsg and recvmsg") removed that on-stack kiocb.
More recently commit fcc77d33a3 ("net: Remove support for AIO on
sockets") removed socket AIO support entirely.
Signed-off-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20260928020420.3097018-1-willemdebruijn.kernel@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
