Move the _set_ethtool_feat() helper from gro_lib.py into lib, so that it
can be reused by the VLAN test added in the next commit. Drop the leading
underscore, now that the helper is exported.
Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Link: https://patch.msgid.link/20260918112529.96039-2-ovidiu.panait.rb@renesas.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
fbnic_add_rx_frag() takes a page_pool reference out of the buffer's
pagecnt_bias before handing the fragment to xdp_buff_add_frag(). If that
call fails it has not taken ownership of the netmem: the fragment is not
recorded in the shared info, and fbnic_put_pkt_buff() will not put the
reference back.
Put the netmem reference back on the failure path.
Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com>
Link: https://patch.msgid.link/20260922-fbnic-refcount-fix-v1-1-31e5862c9893@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
tcp_measure_rcv_mss() recomputes tp->scaling_ratio from
skb->len/skb->truesize and updates tp->window_clamp accordingly. Commit
f5da7c4518 ("tcp: adjust rcvq_space after updating scaling ratio")
made that update go through tcp_set_window_clamp(), which also shrinks
tp->rcv_ssthresh, so every scaling_ratio dip cut the advertised window
as well. Commit 0e125ecfe2 ("tcp: do not change rcv_ssthresh in
tcp_measure_rcv_mss()") restored the plain window_clamp update.
Add a packetdrill test for it, as suggested during the review of that
fix. A fixed SO_RCVBUF pins sk_rcvbuf, so window_clamp can only move
when scaling_ratio does, and the peer announces TCP_MIN_MSS so that
icsk_ack.rcv_mss sits at its 88 byte floor. A single 89 byte segment is
then measured, and 89 bytes of payload in a ~900 byte skb is far below
the 50% that TCP_DEFAULT_SCALING_RATIO assumes, so scaling_ratio and
window_clamp drop sharply. Nothing puts the socket under memory
pressure, so rcv_ssthresh must not move at all.
The test checks the state it depends on instead of assuming it.
tcp_measure_rcv_mss() only measures segments of at least rcv_mss bytes,
so rcv_mss is checked to be 88 before the segment is sent. It is checked
to be 89 afterwards, because rcv_mss is only updated by the same code
that recomputes scaling_ratio, so this proves the segment was measured.
rcv_ssthresh is compared against the value it had right after the
handshake, not against a fixed number, so the test does not depend on
the receive buffer size or on how the architecture accounts skb memory.
Verified on net-next, where it passes for ipv4, ipv6 and
ipv4-mapped-ipv6, and on the same tree with the fix reverted, where it
fails in all three modes with rcv_ssthresh cut from 260684 to 51200.
Signed-off-by: Nathan Gao <zcgao@amazon.com>
Link: https://patch.msgid.link/20260918045021.42138-1-zcgao@amazon.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
When tcf_em_tree_dump() was converted from the legacy rtnetlink
`RTA_PUT_NOHDR` macro (which contained an implicit `goto
rtattr_failure;`) to `nla_put_nohdr()`, the return value check on
`nla_put_nohdr()` was omitted for container/simple matches and raw match
payloads.
If the netlink dump skb runs out of tailroom at `nla_put_nohdr()`, the
error is silently ignored and `match_start->nla_len` is finalized
without the match payload, emitting a malformed/truncated
TCA_EMATCH_TREE_LIST attribute to userspace instead of returning `-1`
via `nla_put_failure` so rtnetlink can reallocate and retry the dump.
Check the return value of `nla_put_nohdr()` in both branches and jump to
`nla_put_failure` on error.
Cc: stable+noautosel@kernel.org # never worked
Signed-off-by: Hui Peng <benquike@gmail.com>
Link: https://patch.msgid.link/20260919210624.3030344-1-benquike@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add IPv4 and IPv6 test cases that exercise GSO packets under BIG TCP
size limits.
1..2
ok 1 tso.big_tcp_ipv4
ok 2 tso.big_tcp_ipv6
Both of them run the existing tx-tcp-segmentation
and tx-tcp6-segmentation tests at the increased TSO maximum.
Additionally, reserve a hugepage and transmit its content using
MSG_ZEROCOPY to produce skb fragments larger than 65536.
Check that the number of retransmissions represents a small
percentage of the total packets sent. Record the number of drops
before and after the send to catch issues with large frag
handling during segmentation.
Signed-off-by: Narcisa Vasile <narcisav.kernel@gmail.com>
Acked-by: Petr Vorel <pvorel@suse.cz>
Link: https://patch.msgid.link/20260921201145.49875-1-narcisav.kernel@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Use literal blocks for 'echo' commands to separate them from
the surrounding text. Otherwise the lines run together, without any
clear break before or after the commands.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://patch.msgid.link/20260921044830.95981-1-rdunlap@infradead.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
proto_flags ORs BIT_ULL(NPC_SPORT_SCTP) and BIT_ULL(NPC_DPORT_SCTP)
twice. The second pair is redundant and does not change the mask.
Drop it.
Signed-off-by: Aryan Sinha <sinha.aryan03@gmail.com>
Reviewed-by: Geetha sowjanya <gakula@marvell.com>
Link: https://patch.msgid.link/20260920122803.6277-1-sinha.aryan03@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Being a DWMAC derivative, the Tegra234 MGBE supports AXI configuration
nodes named stmmac-axi-config and phandle references to them using the
snps,axi-config property.
While at it, add the 10gbase-r PHY mode.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patch.msgid.link/20260921110422.220832-1-thierry.reding@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This 2.5G copper SFP module contains a RTL8221B-VB-CG PHY which can be
accessed using Rollball protocol.
Add a SFP quirk to enable Rollball protocol. It includes a small delay
to avoid unnecessary attempts at reading PHY registers before the
module is ready.
Note: The RTL8221B PHY in this module becomes stuck in a broken state
after attempting to read some registers on MMD 30 while it has already
established a link (this is a general issue with this PHY which happens
when it is configured for rate adaptation mode). This includes the
registers 2/3/8 which are read by "get_phy_c45_ids" during PHY probing.
However, the PHY takes about 4 seconds to establish a link after reset,
so in practice any host that supports TX_DISABLE should be unaffected,
as that puts the PHY into reset.
Signed-off-by: Jan Hoffmann <jan@3e8.eu>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260920192632.72729-2-jan@3e8.eu
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since commit 3d501dd326 ("tcp: do not accept ACK of bytes we never
sent"), tcp_ack() bounds the acceptable old ACK window by
min(tp->max_window, tp->bytes_acked).
When sk->sk_state == TCP_SYN_RECV, tp->bytes_acked is always 0, so
any segment with before(ack, prior_snd_una) immediately returns
-SKB_DROP_REASON_TCP_TOO_OLD_ACK and never reaches the old_ack label
(which returns 0).
Therefore, tcp_ack() can only return 0 in closing states (where old
ACKs are accepted), and can never return 0 in TCP_SYN_RECV.
Simplify the tcp_ack() return value check in tcp_rcv_state_process()
to only check for negative return values and remove the unreachable
!reason branch.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Link: https://patch.msgid.link/20260922010627.2291980-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The MDIO driver matches marvell,mv88e6060 through its OF table, but the
table is not exported. The existing platform alias does not supply the
OF modalias used for this MDIO-enumerated device.
Export the existing table so modular OF-based configurations can load
the switch driver automatically.
The issue was found by our static-analysis tool.
Cc: stable+noautosel@kernel.org # never worked
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Pengpeng Hou <hppiscas@163.com>
Link: https://patch.msgid.link/20260922005049.7647-1-hppiscas@163.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Pick up trivial prep for the series that needs more work.
Tony Nguyen says:
====================
ice: Add ACL support [part]
* '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue:
ice: remove unused ICE_FD_FLUSH_REQ from PF state
ice: rename shared Flow Director functions and structs
====================
Link: https://patch.msgid.link/20260917183927.2692068-1-anthony.l.nguyen@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
spi_dev_get() takes a reference on the SPI device, but neither the
probe error paths nor vsc73xx_spi_remove() ever release it, so the
spi_device can never be freed after the driver has been unbound.
Release the reference on both probe error paths and in remove().
Cc: stable+noautosel@kernel.org # untested fix to unlikely driver error path
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260917104920.2147568-1-vulab@iscas.ac.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
get_ephy_nodes() stores the clock returned by of_clk_get() directly in
gmac->ephy_clk before the reset control is obtained. When the reset
lookup fails, the loop continues or returns without releasing that
clock, and sun8i_dwmac_probe() then jumps to dwmac_remove, which does
not call clk_put(). Keep the clock in a local variable and release it
on the error paths.
Cc: stable+noautosel@kernel.org # untested fix to unlikely driver error path
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260917113654.2149268-1-vulab@iscas.ac.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
__vsock_deliver_tap_skb() is called from vsock_deliver_tap()
under rcu_read_lock().
dev_queue_xmit() does not require the caller to hold a device reference
count, and the device lifetime is already protected by RCU.
Remove the redundant dev_hold(dev) and dev_put(dev) calls.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Stefano Garzarella <sgarzare@redhat.com>
Reviewed-by: Bobby Eshleman <bobbyeshleman@meta.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Link: https://patch.msgid.link/20260921094218.483234-1-edumazet@google.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Jakub Kicinski says:
====================
net: dsa: mv88e6xxx: ethtool n-tuple follow ups
Here are two small tweaks to the mv88e6xxx n-tuple filter handling
suggested by Sashiko when reviewing commit b1fffc2731 ("net: dsa:
mv88e6xxx: bound the policy rule dump by the caller's buffer size")
At the high level the problem is that the driver has shared rule
table but for some ops it doesn't check whether the rule operated
on belongs to the port on which the ethtool request was sent.
I initially thought that this could be intentional, but on closer
look I don't think it really works..
Sending for net-next, because this is AI-induced, build-tested-only
slop-code. The outcome is unlikely and results in mis-configuration,
no crashes.
====================
Link: https://patch.msgid.link/20260918185326.3940857-1-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
ETHTOOL_SRXCLSRLDEL removes the policy the location names out of the
switch-wide IDR without checking which port owns it, then hands it to
mv88e6xxx_policy_apply() along with the port the request arrived on.
Deleting another port's rule therefore purges an ATU entry on and clears
the policy register of the requesting port, while the owning port keeps
its hardware policy - and, with the software object freed, no longer has
a location that can be used to remove it.
Initially I thought that we're just able to delete a rule from one port
using another port as a handle. But if the reading of the code outlined
above is correct, this is just broken, not a "feature" someone could
depend on.
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Link: https://patch.msgid.link/20260918185326.3940857-3-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
chip->policies is one IDR for the whole switch, so the location an
ETHTOOL_GRXCLSRULE caller supplies can name a rule belonging to any port.
mv88e6xxx_get_rxnfc() copies it out without looking at policy->port, which
lets a user on one user port read the MAC address and VID of a policy an
admin installed on another. ETHTOOL_GRXCLSRULE needs no CAP_NET_ADMIN.
The GRXCLSRLCNT and GRXCLSRLALL arms of the same switch statement already
filter on policy->port, which makes the GRXCLSRULE omission look
unintentional. Nonetheless, changing this does carry some regression
risk.
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Link: https://patch.msgid.link/20260918185326.3940857-2-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Oleksij Rempel says:
====================
net: dsa: realtek: EEE support for RTL8365MB-VC
On these switches EEE is enabled by default, but so far it is neither
visible nor controllable from user space. This series wires EEE up to
phylib/phylink on the RTL8365MB-VC integrated-PHY ports so it can be
observed and controlled per port via ethtool
====================
Link: https://patch.msgid.link/20260918091722.3270534-1-o.rempel@pengutronix.de
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Add EEE support on the integrated-PHY ports, controllable per port via
ethtool.
The integrated PHYs have no MMD registers; their EEE registers live in the
switch's OCP space. phylib accesses EEE as MMD registers, so add
phy_{read,write}_c45 realtek_ops that map those MMD accesses onto their OCP
addresses, wired as the user MII bus C45 handlers when the chip provides
them (rtl8366rb etc. unaffected).
The hardware manages LPI on its own, so advertise EEE to phylink with no-op
mac_{en,dis}able_tx_lpi callbacks. The integrated PHYs advertise EEE by
default -- advertised, not necessarily active, since LPI is entered only
once both link partners advertise it and the link idles. No strap pin
selects EEE in the vendor register map, so on the hardware tested this
default is uniform and not board-specific, and marking EEE enabled by
default in phylink matches the PHY's power-on advertisement. Only the
integrated-PHY ports support EEE; the external RGMII ports do not. The LPI
timer is a single global per-speed register, so .set_mac_eee rejects the
per-port TX LPI knobs rather than silently ignoring them.
This assumes the integrated PHYs advertise EEE out of reset regardless of
board configuration; should a strap or other non-kernel mechanism disable
EEE advertisement on some board or chip in the family, enabling it by
default here would change that default behaviour.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Reviewed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Link: https://patch.msgid.link/20260918091722.3270534-4-o.rempel@pengutronix.de
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Extract the two OCP address halves with FIELD_GET() before handing them
to FIELD_PREP() to build the ADDRESS register value.
rtl8365mb_phy_ocp_prepare() previously fed FIELD_PREP() the raw
ocp_addr >> 1 and >> 6. FIELD_PREP() masks the value to the field at run
time, so that was correct for the current callers, which all pass a
run-time register address.
FIELD_PREP()'s compile-time width check only fires for a compile-time
constant value. None reached it here: the address is computed as
PHYREG_BASE + regnum * 2 from a run-time regnum. The EEE support that
follows adds callers with constant OCP addresses (0xa5c4 etc.); clang
folds those into the inlined ocp_prepare(), so the shifted constant now
reaches the check, overflows the 5-/4-bit field and breaks the build
(gcc does not fold it here). FIELD_GET() narrows each half to the field
width first, so the value already fits.
No functional change.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260918091722.3270534-3-o.rempel@pengutronix.de
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The RTL8365MB-VC PHYs are integrated into the switch and have no MMD
registers of their own. What phylib would access as MMD registers (the EEE
ability/advertisement) lives in the switch's OCP registers instead.
For a C22 PHY, phy_read_mmd()/phy_write_mmd() use C22 indirect-MMD, which
this hardware does not implement. Point .read_mmd/.write_mmd at
genphy_{read,write}_mmd_c45() so phylib issues those MMD accesses over C45,
where the DSA user MDIO bus can carry them to the switch's OCP registers.
This patch only redirects the MMD access path; it does not enable EEE. The
OCP mapping (the DSA bus .read_c45/.write_c45 handlers) and EEE support are
added by the following patch. Until then an MMD access returns -EOPNOTSUPP;
the only one that runs is the EEE-ability read in phy_probe(), which phylib
ignores, so probe, link and traffic are unaffected and ethtool --show-eee
reports EEE unsupported -- the same as before this series, not a regression
(verified on an RTL8365MB-VC).
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Reviewed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Link: https://patch.msgid.link/20260918091722.3270534-2-o.rempel@pengutronix.de
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Victor Nogueira says:
====================
net/sched: complete action notification accounting
The action notification paths size their skb from each action's
get_fill_size() callback, but three gaps remain: one callback undercounts
(TCA_MIRRED_BLOCKID), five actions have no callback at all, and the
TCA_ROOT_EXT_WARN_MSG attribute is unbudgeted.
Patch 1 fixes the mirred callback for TCA_MIRRED_BLOCKID.
Patch 2 adds get_fill_size() to act_simple, act_mpls, act_nat, act_skbmod
and act_connmark, the five actions that still lack one.
Patch 3 budgets TCA_ROOT_EXT_WARN_MSG.
====================
Link: https://patch.msgid.link/QDISC-RYTB.v1.20260918093205@mojatatu.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
tca_get_fill may emit TCA_ROOT_EXT_WARN_MSG from extack->_msg.
The string is whatever NL_SET_ERR_MSG and friends stored, so its
length is bounded only by the caller, and nothing in the budget that
tcf_add_notify_msg and tcf_del_notify_msg hand to alloc_skb
accounts for it. The notify skb can therefore be sized smaller than
what tca_get_fill goes on to write into it.
The attribute reaches a successful add because tcf_action_init keeps
going when an action that is not skip_sw fails to offload:
err = tcf_action_offload_add(act, extack);
if (tc_act_skip_sw(act->tcfa_flags) && err)
goto err;
The action is created while extack->_msg still holds the offload
diagnostic, and tcf_add_notify echoes it back. A pedit action with mixed
key commands (one SET and one ADD) takes that path: the non-bind
tcf_pedit_offload_act_setup sets "Unsupported pedit command offload" and
returns -EOPNOTSUPP.
In practice, no underbudgeting has been observed because of this, and the
gap is not easy to reach given some other spots account for more than
necessary. However, for correctness, budget the attribute so the size
handed to alloc_skb covers what tca_get_fill can write.
Reported-by: Sashiko <sashiko-bot@kernel.org>
Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260824153903.4143642-1-victor@mojatatu.com
Co-developed-by: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: Victor Nogueira <victor@mojatatu.com>
Link: https://patch.msgid.link/QDISC-RYTB.v1.20260918093205@mojatatu.com.3
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
act_simple, act_mpls, act_nat, act_skbmod and act_connmark each have a
tcf_*_dump but no .get_fill_size callback, so tcf_action_fill_size
budgets only the shared attributes and omits the per-action
TCA_*_PARMS and option bytes the dump emits.
Add a callback to each, sized from the attributes its dump emits. Size
every optional attribute unconditionally: reading the current flags to
size it conditionally would race a concurrent replace, which can flip
the attributes between sizing and dumping.
Reported-by: Sashiko <sashiko-bot@kernel.org>
Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260824153903.4143642-1-victor@mojatatu.com
Co-developed-by: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: Victor Nogueira <victor@mojatatu.com>
Link: https://patch.msgid.link/QDISC-RYTB.v1.20260918093205@mojatatu.com.2
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
tcf_mirred_get_fill_size budgets only TCA_MIRRED_PARMS, but
tcf_mirred_dump also emits TCA_MIRRED_BLOCKID whenever the action was
created with a block instead of a device, so the budget falls 8 bytes
short of what the dump may produce for such actions.
Account for TCA_MIRRED_BLOCKID unconditionally: reading tcfm_blockid to
size it conditionally would race a concurrent replace, which can flip the
action between device and block between sizing and dumping.
Reported-by: Sashiko <sashiko-bot@kernel.org>
Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260824153903.4143642-1-victor@mojatatu.com
Co-developed-by: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: Victor Nogueira <victor@mojatatu.com>
Link: https://patch.msgid.link/QDISC-RYTB.v1.20260918093205@mojatatu.com.1
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
- brcmfmac: FT/OKC roaming offload
- ath12k: IPQ5332 platform infrastructure
- cfg80211/mac80211: non-STA TX/RX infrastructure
for MLO to fix address translation bugs
- the rest is mostly minor cleanups etc.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEpeA8sTs3M8SN2hR410qiO8sPaAAFAmqxHzUACgkQ10qiO8sP
aACS2g/9HLt0g35/O74zeEyD1+J37Xu7oXNdbG7CWGPnTqxupvSeNxrLJN8ToSRj
Gm80BGEuFxF+OhR4ZuvwGd2sUjmprZ6l27CIrqiEIHWrI3+kFyqkOBHKu2DuQ6/m
QyvXn6tAKwQ9YPOyfpmyVYszujT/TyEmYkPvgX8xeNeTStwUhDCT/G3/NIN2/eyn
jR5po2eeg3M12V93mTb9usHRkaWN5NIfsUTAuN5noHv4o8v8kbwbTuQiVMjlMIxJ
5rEen2BidPJuxfSXeYK1JVgEzs1j+JKvHF+Wd1VCE011iZaF3lp8d9CF+Wn15v0Z
UfvXzrmU3zoQb2bKyCSQPBskHI8r3zDpkxzZoifGBucKsf0lm3pqH2EVGiBpTPga
OvUp2/4Z75RGKtC9Hao7a6rofPDyZTyiaG+hHtsOs8qTDBSQZGt6sAbv1b4iVziw
VpZoyocBUyIKqX8SST14kLbqG8crEso08Zy4xE4JbSV7VBl96Qwck4hqmiDL0cAC
Vuq5Pg/OCN6A2TWvJElnWJiWE96sZ0wF9T00WmMEGPBuyZWVk4RkfCGzQJ1SK/1K
s8NrFdqqcIsICLNQTO7ofBeaky7/55m0It7OfcvHIQwo1DWUZ//WeMptSKWP2BBb
rVBgUtPlQhxvuNVNysvkgUnjS7Fh8/18JvE81yX8sIN6DGgduxE=
=Nzgx
-----END PGP SIGNATURE-----
Merge tag 'wireless-next-2026-09-21' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next
Johannes Berg says:
====================
More changes, including drivers:
- brcmfmac: FT/OKC roaming offload
- ath12k: IPQ5332 platform infrastructure
- cfg80211/mac80211: non-STA TX/RX infrastructure
for MLO to fix address translation bugs
- the rest is mostly minor cleanups etc.
* tag 'wireless-next-2026-09-21' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (101 commits)
dt-bindings: net: wireless: Convert WL1251 to DT schema
libertas: mesh: remove unused and undocumented sysfs attribute groups
wifi: mac80211: fix multi-link UHR association
wifi: nl80211: rename no-ACK bitmap to TID bitmap
wifi: radiotap: correct EHT TB U-SIG 1 B20:25
wifi: ieee80211: fix FTM bufferable check
wifi: mac80211: allow advertising 20 MHz-only non-AP STA
wifi: mac80211: WARN on 40 MHz HT/HE mismatch
wifi: mac80211: tests: fix memory leak
wifi: mac80211: use assign_bit() where applicable
wifi: mac80211: pass error station if non-STA transmit was requested
wifi: mac80211: pass station to ieee80211_tx_skb_tid
wifi: mac80211: report to cfg80211 when no STA is known for a frame
wifi: cfg80211: add attribute for TX/RX denoting there is no station
wifi: mac80211: rework RX packet handling
wifi: mac80211: refactor RX link_id and station handling
wifi: mac80211: change public RX API to use link stations
wifi: iwlwifi: use link_sta internally to the driver
MAINTAINERS: Replace wireless.wiki.kernel.org links
wifi: brcmfmac: log the firmware status when a connect fails
...
====================
Link: https://patch.msgid.link/20260921121635.195723-3-johannes@sipsolutions.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
__netlink_deliver_tap_skb() is called from netlink_deliver_tap()
under rcu_read_lock().
dev_queue_xmit() does not require the caller to hold a device reference
count, and the device lifetime is already protected by RCU (the netlink tap
is unlinked and waited for via grace periods prior to device destruction).
Remove the redundant dev_hold(dev) and dev_put(dev) calls.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260921093947.477658-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Nikolay Aleksandrov says:
====================
net: bridge: vlan: broadcast fwding path optimizations
This patch-set is the first step to removing unnecessary VLAN hash lookups
from the bridge fast-path and also provides additional broadcast path
optimization by considering only the port-VLANs that actually participate
in the VLAN instead of all bridge ports. Combined these changes bring
considerable improvements (see patch 8's commit message) and open
the path to do the same for the most common fdb forwarding path.
As expected the pathological cases have the largest gain,
e.g. if we have 1 client / VM facing port and 1 upstream port
only participating in a VLAN with many other bridge ports, we consider only
those 2 when broadcasting in that VLAN.
For up to 8 ports we only use the port-VLAN list as the array doesn't make
much of a difference and is unnecessary. Note that the array is rebuilt on
every member add or delete when >8 members, I tested that and could do
2000 VLAN add/delete with 64 port-VLAN members / sec on my test VM.
If it ever becomes a problem we can optimize it further, for the time
being I prefer it is simpler.
====================
Link: https://patch.msgid.link/20260918152950.1938259-1-razor@blackwall.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
We can remove more unnecessary VLAN lookups if we pass the port-VLAN
entry to the neighbour suppression helpers so they can use it directly
instead of resolving it again. Use a vid wrapper for callers which don't
have the port-VLAN entry. This removes up to two additional VLAN hash
lookups per flooded egress port for packets marked as proxy replied.
Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260918152950.1938259-10-razor@blackwall.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Introduce struct br_fwd_dst to keep an egress port together with its
corresponding VLAN while passing it through the forwarding helpers. This
allows paths which already resolved the port VLAN to preserve that
information for later egress processing. maybe_deliver() now returns the
clone error directly and we pass it separately to br_flood_finish()
avoiding the error-pointer encoding and decoding which overloaded the
previous port pointer.
No functional changes intended.
Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260918152950.1938259-8-razor@blackwall.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Walking the master VLAN's port-VLAN list avoids considering ports outside
the VLAN but its pointer chasing becomes more expensive than array when
many ports participate. Add an rcu array of port-VLAN pointers for larger
flood sets. Rebuild and publish the array under RTNL when VLAN membership
changes. Continue using the list for small flood sets and as a fallback
if the array allocation fails.
Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260918152950.1938259-7-razor@blackwall.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Use the port-VLAN list that is in every master VLAN and consider only
participating port-VLANs when flooding packets. This is the first
optimization that greatly improves performance for sparse port VLANs
e.g. 2 out of 32 ports participating in a single VLAN: before the
bridge would consider all 32 ports and forward the packet only through
the 2, now it will only consider the participating 2 ports.
Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260918152950.1938259-6-razor@blackwall.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Keep a list of all port-VLANs that have been created within their
master VLAN. The list is rcu-safe and will be used for optimizing
the flood path.
Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260918152950.1938259-5-razor@blackwall.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
VLAN groups cache the pvid and its state separately requiring state
updates to keep both copies synchronized. Lockless readers can also
observe the pvid and state from different updates. Cache an rcu protected
pointer to the pvid vlan entry instead. This makes the vlan entry the
single source of truth and lets the ingress path reuse it without another
lookup. It also makes the vlan entry always available at the ingress path
for subsequent forwarding-path optimizations.
Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260918152950.1938259-4-razor@blackwall.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Factor out port flooding code into its own helper, it will be used by later
changes to flood to specific port VLANs. No functional changes intended.
Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260918152950.1938259-3-razor@blackwall.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Factor out the common flood completion handling shared by br_flood and
br_multicast_flood into a new helper - br_flood_finish. No functional
changes intended.
Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260918152950.1938259-2-razor@blackwall.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In preparation for making the devm_kmalloc family of allocators type
aware, we need to make sure that the returned type from the allocation
matches the type of the variable being assigned. (Before, the allocator
would always return "void *", which can be implicitly cast to any
pointer type.)
This is allocating room for a copy of ikpu_action_entries, which is an
array of struct npc_kpu_profile_action, but it asked for a single object
the size of the whole array, which would make the allocation type a
pointer to the array rather than the "struct npc_kpu_profile_action *"
being assigned. Allocate ARRAY_SIZE-many entries instead. The resulting
allocation size is the same.
Build tested ARCH=x86_64 allmodconfig with GCC 16.2.0:
drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.o
Signed-off-by: Kees Cook <kees+treewide@kernel.org>
Reviewed-by: Ratheesh Kannoth <rkannoth@marvell.com>
Link: https://patch.msgid.link/20260917211409.i.425-kees@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
qdisc_alloc_handle scans for a free auto-handle by probing the
per-device qdisc hash one handle at a time. With the 16-bucket hash
populated by tens of thousands of qdiscs, the failing scan is O(N^2)
under rtnl_lock. A single failing add then holds rtnl_lock for most of a
second, and rtnl_lock is global, so all other netlink configuration is
blocked for that time.
First try the handle after the rotating cursor with one qdisc_lookup,
as the first iteration of the current loop does; that handle is
normally free. Only when it is taken, build a bitmap of the occupied
auto-handle majors in one pass over the hash and pick the first free
major from the cursor. The scan is cyclic over all 0x7FFF majors
starting from the same autohandle + 1 position as the current loop, so
it returns the same handle for the same device state and fails only
when all 0x7FFF majors are taken.
The root qdisc is seeded separately because qdisc_hash_add skips
parent == TC_H_ROOT.
When the next handle is free, only the single qdisc_lookup of the
current loop's first iteration runs; when it is taken, one O(N) walk
follows.
Measured as tc wall time on a defconfig kernel in a 2-vCPU guest, with
an HTB root holding 32768 classes and all 32767 auto-handles in use (a
no-op tc command takes 5-6.5 ms):
unpatched patched
failing add, space exhausted 613-749 ms 8-10 ms
add after a mid-range delete 572-573 ms 9 ms
The failure path returns -ENOMEM (bitmap allocation) or -ENOSPC (space
exhausted) through a handle out-parameter instead of the overloaded 0
return. Since either error is now possible, the extack message changes
from "Maximum number of qdisc handles was exceeded" to "Failed to
allocate a qdisc handle".
Reported-by: Vega <vega@nebusec.ai>
Co-developed-by: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: Victor Nogueira <victor@mojatatu.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260918135157.163015-1-victor@mojatatu.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The HI13X1 TX descriptor stores send_size and data_offset in 16-bit
fields, unlike the 32-bit send_size field in the other descriptor
layout. The transmit path nevertheless converts both HI13X1 fields with
cpu_to_be32() before assigning them to u16 members.
On a little-endian CPU, the conversion moves these small values into the
upper half of the 32-bit result and the assignment discards that half.
The descriptor consequently loses the packet size and cache-line offset.
Use cpu_to_be16() for the two HI13X1 fields. Leave the other layout's
32-bit size conversion unchanged.
The issue was found by our static-analysis tool.
Cc: stable+noautosel@kernel.org # untested fix for ancient HW
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Jijie Shao <shaojijie@huawei.com>
Signed-off-by: Pengpeng Hou <hppiscas@163.com>
Link: https://patch.msgid.link/20260920033641.13590-1-hppiscas@163.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The tun_vnet_udptnl fixture creates a fresh tap device, assigns it a
fixed MAC address and installs the outer neighbor entry as
NUD_PERMANENT. On systems where systemd-udevd is running and a systemd
.link file sets
MACAddressPolicy=persistent
(the default shipped by systemd in 99-default.link, so this is what
most systemd-based hosts inherit), systemd-udevd's net_setup_link
builtin asynchronously sends an RTM_SETLINK to reassign the freshly
created tap device's MAC to a machine-persistent value. When that
lands after the fixture has configured the device, both directions
break:
- recv_gso_packet transmits through the tap, and the address change
flushes the neighbor entry the fixture installed:
do_setlink
-> netif_set_mac_address
-> call_netdevice_notifiers(NETDEV_CHANGEADDR)
-> ndisc_netdev_event (arp_netdev_event for an IPv4 outer)
-> neigh_changeaddr
-> neigh_flush_dev(tbl, dev, /* skip_perm = */ false)
so the packet hits __neigh_create() and waits on neighbor resolution
that never completes.
- send_gso_packet writes frames addressed to the MAC the fixture
assigned. Once the tap has a different address, eth_type_trans()
marks them PACKET_OTHERHOST and the IP receive path drops them.
Either way nothing arrives before the receive timeout, and the test
fails with, for example:
tun.c:947:send_gso_packet:Expected ret (0) == variant->data_size (1)
tun.c:948:send_gso_packet:Expected r_num_mss (0) == variant->r_num_mss (1)
tun.c:962:recv_gso_packet:Expected ret (0) == variant->data_size (1)
The failure is non-deterministic and reproduces on a plain
systemd-based VM with no containers.
Fix by calling unshare(CLONE_NEWNET) from both fixture setups. The
harness runs each test in its own forked process, so every test gets a
private network namespace that is torn down with it, and all tap and
geneve devices are created in a namespace that systemd-udevd (running
in the init netns) does not watch, so its RTM_SETLINK never fires
against them.
Creating a network namespace needs CAP_SYS_ADMIN in the current user
namespace and CONFIG_NET_NS=y, neither of which the tests required
before. Where they are unavailable the unshare() is reported with
SKIP() rather than aborting, so the binary still emits a full TAP
stream and a runner can tell "network namespaces unavailable" apart
from a real tun/tap regression.
Verified on a plain systemd-based VM running the affected kernel.
Without the fix, 1000 sequential invocations of
tun -r tun_vnet_udptnl.4in6_nogsosz_1byte.recv_gso_packet
fail 10 times, and 2 out of 20 full runs of the test binary fail. With
the fix there are no failures in either case.
Reported-by: Po-Hsu Lin <po-hsu.lin@canonical.com>
Closes: https://bugs.launchpad.net/bugs/2158217
Signed-off-by: Edoardo Canepa <edoardo.canepa@canonical.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260917111520.2614448-1-edoardo.canepa@canonical.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
mvneta_swbm_build_skb() is only invoked from mvneta_poll(), the NAPI
poll routine, so it always runs in NAPI context. Use napi_build_skb()
instead of build_skb() to source the skb head from the per-CPU NAPI
cache, avoiding a per-packet kmem_cache_alloc() of the skb head.
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260917-mvneta-napi-poll-v1-1-fb57604932d3@oss.qualcomm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The IXP46x PTP driver matches intel,ixp46x-ptp-timer via its OF table,
but does not export that table. A module build therefore lacks the OF
alias used to automatically load the timer driver.
Export the existing table without changing the matching or probe logic.
The issue was found by our static-analysis tool.
Cc: stable+noautosel@kernel.org # never worked
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Pengpeng Hou <hppiscas@163.com>
Link: https://patch.msgid.link/20260920034557.17734-1-hppiscas@163.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The SLIC driver has a PCI ID table connected to its pci_driver, but does
not export it. Its module therefore lacks the PCI aliases used to
automatically load it for the supported Alacritech adapters.
Export the existing PCI table without changing device matching.
The issue was found by our static-analysis tool.
Cc: stable+noautosel@kernel.org # never worked
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Lino Sanfilippo <LinoSanfilippo@gmx.de>
Signed-off-by: Pengpeng Hou <hppiscas@163.com>
Link: https://patch.msgid.link/20260920034651.18109-1-hppiscas@163.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
setup_ipv4() creates a GRETAP tunnel with FOU encap and configures a FOU
port via "ip fou add". Both require the fou module, which cannot be
auto-loaded.
The test assumes CONFIG_NET_FOU=y, which matches the default selftests
config, but fails on kernels built with CONFIG_NET_FOU=m. Without the fou
module, tunnel creation fails and the test reports a false failure with
0/100 received packets:
RTNETLINK answers: Invalid argument
TEST: FOU/GRETAP IPv4 multicast encap resubmit (received 0/100) [FAIL]
Load the fou module and skip the subtest cleanly when unavailable. This
matches the existing fou6 handling in this script and the pattern used in
pmtu.sh.
modprobe is a no-op when CONFIG_NET_FOU=y, so default selftest builds
remain unchanged.
Signed-off-by: Qingshuang Fu <fuqingshuang@kylinos.cn>
Link: https://patch.msgid.link/20260917033049.792209-1-fuqingshuang@kylinos.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Stanislav Fomichev says:
====================
net: devmem: remove gen_pool from dma-buf allocations
Replace devmem's gen_pool based fixed-size allocator with a binding-level
freelist similar to the one used by io_uring zero-copy receive.
This is motivated by allocation latency observed in the NAPI receive path:
[ 1036.228913] ? gen_pool_create+0x90/0x90
[ 1036.228915] net_devmem_alloc_dmabuf+0x1f/0x60
[ 1036.228918] mp_dmabuf_devmem_alloc_netmems+0x17/0x80
[ 1036.228920] mlx5e_post_rx_mpwqes+0xdbe/0xdd0
[ 1036.228926] mlx5e_napi_poll+0x113/0x830
[ 1036.228928] ? sched_clock+0x5/0x10
[ 1036.228931] ? wake_up_process+0x778/0x14b0
[ 1036.228933] net_rx_action+0x15d/0x570
[ 1036.228934] ? update_rq_clock+0x31/0x240
[ 1036.228937] ? __napi_schedule+0x55/0xa0
[ 1036.228938] ? mlx5_eq_comp_int+0x137/0x230
[ 1036.228940] ? atomic_notifier_call_chain+0x36/0x90
[ 1036.228943] ? sched_clock+0x5/0x10
[ 1036.228944] ? sched_clock_cpu+0xc/0x170
[ 1036.228947] irq_exit_rcu+0x12b/0x370
[ 1036.228950] common_interrupt+0x85/0x90
udmabuf can create a very large number of SG entries. In the worst case,
devmem ends up adding one gen_pool chunk for each net_iov allocation
unit backed by those entries. The gen_pool allocation path then has to
traverse a linked list that can become too long for this hot path.
Patch 1 removes the gen_pool and replaces it with a simple freelist of
net_iov pointers protected by the same spin_lock_bh() pattern used by
io_uring zcrx. Patch 2 removes the now-unnecessary chunk owner wrapper by
embedding the net_iov_area directly in the dma-buf binding. Patch 3
batches freelist allocations.
====================
See mailing Link for performance evaluation.
Link: https://patch.msgid.link/20260917181116.3319017-1-sdf@fomichev.me
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
