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>
Rename net_devmem_alloc_dmabuf() into net_devmem_alloc_dmabuf_bulk() and
make it refill page pool with up to PP_ALLOC_CACHE_REFILL NIOVs,
similar to io_pp_zc_alloc_netmems(). That should amortize recently
introduced freelist_lock.
Reviewed-by: Mina Almasry <almasrymina@google.com>
Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/20260917181116.3319017-4-sdf@fomichev.me
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
After replacing the gen_pool with a binding-level freelist, devmem no
longer needs a separate chunk owner object. There is only one
net_iov_area for the binding, so store it directly in struct
net_devmem_dmabuf_binding.
Derive the binding from net_iov_owner() with container_of(), matching the
pattern used by io_uring zcrx. This removes the leftover
dmabuf_genpool_chunk_owner wrapper and its allocation/free path.
Reviewed-by: Mina Almasry <almasrymina@google.com>
Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/20260917181116.3319017-3-sdf@fomichev.me
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
devmem only needs fixed-size net_iov allocations for each dma-buf binding.
The gen_pool tracks the same free set indirectly through DMA addresses,
which makes devmem depend on the generic allocator even though the users
are fixed-size net_iov chunks.
Mirror the io_uring zcrx model more closely by keeping a binding-level
freelist protected by spin_lock_bh(). Use a single net_iov_area owner for
the binding, populate each net_iov's DMA address while walking the SG
table, and check at teardown that all net_iovs have returned to the
freelist.
Validate the DMA-BUF size against the net_iov size up front and derive the
RX and TX entry count from it, avoiding a separate SG-table pass.
Drop the NET_DEVMEM select of GENERIC_ALLOCATOR now that devmem no longer
calls gen_pool APIs.
Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/20260917181116.3319017-2-sdf@fomichev.me
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Before commit c5c37af6ec ("tcp: Convert do_tcp_sendpages() to use
MSG_SPLICE_PAGES"), do_tcp_sendpages() did not call
tcp_rate_check_app_limited() internally, so callers needed an explicit
tcp_rate_check_app_limited() to cover it. That commit replaced
do_tcp_sendpages() with direct tcp_sendmsg_locked() calls, which perform
the check on every path that queues data. The outer call became redundant
but was left in place.
The site changed here, tls_push_sg(), holds the socket lock and invokes
tcp_sendmsg_locked() on every iteration. The early-return paths in
tcp_sendmsg_locked() that skip tcp_rate_check_app_limited() -- the
MSG_ZEROCOPY allocation failure and MSG_FASTOPEN branches -- return
without queueing any MSG_SPLICE_PAGES data, so there is no functional
consequence from omitting the outer check.
A potential benefit of this change is that it facilitates future reuse of
tls_push_sg() for KTLS support in protocols beyond TCP, such as MPTCP.
Since tcp_rate_check_app_limited() is TCP-specific while sendmsg_locked()
is a generic interface in struct proto_ops, this change allows us to switch
to different protocols via sk->sk_socket->ops->sendmsg_locked() without
carrying protocol-specific assumptions.
Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
Link: https://patch.msgid.link/5bc803abb4e27054eaffc8b26db7812e6347b0dd.1789634247.git.tanggeliang@kylinos.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Sagi Maimon says:
====================
ptp: ocp: add TAP CPLD support for ADVA TimeCard X1
The ADVA TimeCard X1 (PCI device 0x0410) carries a Lattice MachXO3 CPLD
on the TMC I2C bus. This series adds access to it and an update path
through devlink flash.
The card has two I2C controllers. Linux registers only the one at
0x00150000, normally routed to the config EEPROMs; the one at 0x00120000
belongs to the on-card MicroBlaze and is routed to the TMC or M.2 bus as
its firmware selects. A request/grant handshake re-routes the host
controller onto the TMC bus, where the PCA9548 and the CPLD behind its
channel 0 live. Everything here is built on that handshake.
Patches 1 and 2 are pre-existing probe-error-path bugs that were buried
in the feature commit in v13; they are split out with Fixes: tags. Patch
1 is also a prerequisite: patch 3 adds a mutex that ptp_ocp_detach()
destroys, so devlink has to be unregistered first. Patch 3 adds the bus
arbitration and the read-only interfaces, patch 4 the flashing.
====================
Link: https://patch.msgid.link/20260916153242.157171-1-sagi.maimon@adtran.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The Lattice MachXO3 CPLD on the ADVA TimeCard X1 is programmed over I2C
using in-system programming (ISP). Build on the TMC bus arbitration added
previously and expose the update path as a devlink flash component, next
to the card flash the driver already writes through devlink.
The component is named fw.cpld and reported as a running version, so
->info_get() both publishes the USERCODE of the image currently in the
part and lets the core accept the name:
devlink dev flash pci/0000:02:00.0 file adva-cpld.bin component fw.cpld
Flashing acquires the bus, erases the configuration flash, programs the
image page by page and activates it with the MachXO3 REFRESH command,
reporting progress with the standard devlink notifications. The CPLD is
required to come back with DONE set, not busy and no error code before the
update is called successful, as drivers/fpga/machxo2-spi.c does.
The whole sequence runs under cpld_lock and the i2c adapter lock, so an
EEPROM read blocks for as long as programming takes; the alternative is
reading the TMC bus instead. Flashing is privileged:
DEVLINK_CMD_FLASH_UPDATE carries GENL_ADMIN_PERM.
Signed-off-by: Sagi Maimon <maimon.sagi@gmail.com>
Link: https://patch.msgid.link/20260916153242.157171-5-sagi.maimon@adtran.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The ADVA TimeCard X1 carries a Lattice MachXO3 CPLD on its TMC I2C bus.
Reaching it means taking that bus from the on-card MicroBlaze first.
The card has two I2C controllers. Linux registers only the one at
0x00150000, normally routed to the config EEPROMs; the one at 0x00120000
belongs to the MicroBlaze and is routed to the TMC or M.2 bus as its
firmware selects. A request/grant handshake re-routes the host controller
onto the TMC bus, where the PCA9548 and the CPLD behind its channel 0
live. An operation takes the i2c core adapter lock for the whole grant
window and uses __i2c_transfer() internally; without that, a concurrent
transfer from ptp_ocp_read_eeprom(), from the nvmem attributes or from the
at24 sysfs files would be issued onto the TMC bus instead of to the
EEPROM. The hand-back waits for the firmware to drop the grant before the
adapter lock is released, for the same reason.
On top of the arbitration this adds two read-only interfaces: a root-only
cpld_status attribute reporting the flags in the CPLD status register, and
the Lattice device ID as the fixed devlink version cpld.id. Reading the
ID claims the bus, so it must not sit on DEVLINK_CMD_INFO_GET, which
carries no GENL_ADMIN_PERM; the driver reads it once from its own worker,
as soon as the i2c adapter has registered, and info_get() reports the
cached value.
Signed-off-by: Sagi Maimon <maimon.sagi@gmail.com>
Link: https://patch.msgid.link/20260916153242.157171-4-sagi.maimon@adtran.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Two problems on the dpll error paths in ptp_ocp_probe().
dpll_device_register() takes a second reference and stores bp as the
registration private data, and only dpll_device_unregister() drops it.
out_dpll dropped bp->tracker but never unregistered, so a dpll_pin_get()
or dpll_pin_register() failure left the device registered and visible to
userspace with a priv pointer into the storage devlink_free() releases a
few lines later, as well as leaking the registration object.
A failing dpll_device_register() jumped to the same label as the failing
dpll_device_get(), so the reference taken by dpll_device_get() was never
dropped either. Give that case its own label.
Cc: stable+noautosel@kernel.org # untested fix to unlikely driver error path
Signed-off-by: Sagi Maimon <maimon.sagi@gmail.com>
Link: https://patch.msgid.link/20260916153242.157171-3-sagi.maimon@adtran.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
devlink_register() runs before the dpll setup in ptp_ocp_probe(), but the
failure paths after it went straight to ptp_ocp_detach() and then
devlink_free(), which opens with ASSERT_DEVLINK_NOT_REGISTERED(devlink).
Any dpll failure during probe therefore freed a devlink instance that was
still registered.
Route those paths through a new out_devlink label that unregisters first,
matching the order ptp_ocp_remove() already uses.
Cc: stable+noautosel@kernel.org # untested fix to unlikely driver error path
Signed-off-by: Sagi Maimon <maimon.sagi@gmail.com>
Link: https://patch.msgid.link/20260916153242.157171-2-sagi.maimon@adtran.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
A recent patch introduced a call to devm_cxl_probe_mem(), which is only
available when CXL_MEM is enabled. If CXL_MEM is in a loadable module,
this causes a link failure for a builtin driver:
s390-linux-ld: drivers/net/ethernet/sfc/efx_cxl.o: in function `efx_cxl_init':
efx_cxl.c:(.text+0x156): undefined reference to `devm_cxl_probe_mem'
Adapt the dependency to require CXL_MEM instead of CXL_BUS, which
we know is available when CXL_MEM is.
Fixes: 0418860ef2 ("sfc: obtain and map cxl range using devm_cxl_probe_mem")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Alejandro Lucero <alucerop@amd.com>
Link: https://patch.msgid.link/20260917155519.2121486-1-arnd@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
VCAP_KUNIT_TEST enables DEBUG_FS even when the kernel configuration
leaves it disabled. Remove the selection, following the dependency rule
in Documentation/dev-tools/kunit/style.rst.
The debugfs implementation and its tests are already built only with
DEBUG_FS. The other VCAP tests can run without it.
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Reviewed-by: Daniel Machon <daniel.machon@microchip.com>
Acked-by: David Gow <david@davidgow.net>
Link: https://patch.msgid.link/20260917064736.77354-1-kmehltretter@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
gcc warns about an unused function here because the __maybe_unused
attribute is in the wrong part of the prototype:
drivers/net/dsa/motorcomm/leds.c:352:1: error: 'yt921x_cled_hw_control_get_device' defined but not used [-Werror=unused-function]
352 | yt921x_cled_hw_control_get_device(struct led_classdev *led_cdev)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Move the __maybe_unused attribute to refer to the function rather
than the returned object.
Fixes: 9af9a81682 ("net: dsa: motorcomm: Add LED support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20260916082707.3973287-1-arnd@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
