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>
Convert the Texas Instruments WL1251 Wireless LAN Controller bindings to DT
schema.
During the conversion, the following updates were made:
- Added the 'clocks' property. It was missing from the txt binding but
is used in device trees (omap3-n900.dts).
- Added 'spi-cpol' and 'spi-cpha'. These were present in the original
txt binding's example but missing from its property list.
- 'vio-supply' and 'spi-max-frequency' are no longer required. The txt
binding listed them as required, but they are only applicable when
the chip is connected via SPI.
Signed-off-by: Eduard Bostina <egbostina@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260917204354.3017427-1-egbostina@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
7e79b38fe9 ("libertas: register sysfs groups properly")
changed the code to use struct net_device member sysfs_groups
array indices 1 and 2. However only one device-specific group
is supported by net core, see netdev_register_kobject().
As a result groups boot_opts_group and mesh_ie_group are
overwritten with net core internal groups.
Referenced change was done 5 yrs ago, and apparently nobody
has missed the sysfs attributes in the meantime. So I dare
to remove them, especially as they aren't documented under
Documentation/ABI.
Signed-off-by: Heiner Kallweit <hkall@kernel.org>
Link: https://patch.msgid.link/6810ccfb-0453-4bdc-bb03-d51c3f3c6e18@kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Rename the NL80211_ATTR_NOACK_MAP attribute to be called
NL80211_ATTR_TID_BITMAP, allowing it to be reused in more
contexts. The interpretation stays for the only command
using it now (NL80211_CMD_SET_NOACK_MAP.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Link: https://patch.msgid.link/20260916120620.823bfa05f5f5.Ibb334016129512921b0aa5236ee4c670d83d0f95@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
802.11 Clause 27 (HE) already defined a 20 MHz-only non-AP
HE STA in the 5 GHz band, where VHT is required, although
VHT in Clause 21 requires 20, 40 and 80 MHz support. The
VHT requirement is implemented in mac80211, but the later
allowance for 20 MHz-only since HE wasn't.
Allow a device to be a 20 MHz-only non-AP STA and require
that it support VHT, but not that it has 80 MHz support,
if it's HE as well.
Link: https://patch.msgid.link/20260916120127.6e74579d46db.I628aed79ec7f9bf2f8e770b4866ed98cf1ddbe60@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add mailmap entries for some Qualcomm Wi-Fi developers now using
@oss.qualcomm.com credentials.
For ath12, add support for the qcom,calibration-variant Device Tree
property and add more infrastructure for the IPQ5332 platform.
Other than that, just an assortment of cleanups and minor bug fixes across
the "ath" family of drivers that aren't urgent enough to go through the
"current" process.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQQ/mtSHzPUi16IfDEksFbugiYzLewUCaqqncgAKCRAsFbugiYzL
e/I7AP9XZ+pkgUYw1MUUBiey/Ov/bVQKd/DYU3jRr6Zz0lJw3AEA+ZpSxbef1AcK
txnHjzKtKNLm5dXsvZay9NOR3wVVYAM=
=M4Qu
-----END PGP SIGNATURE-----
Merge tag 'ath-next-20260916' of git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath
Jeff Johnson says:
==================
ath.git patches for v7.4 (PR #1)
Add mailmap entries for some Qualcomm Wi-Fi developers now using
@oss.qualcomm.com credentials.
For ath12, add support for the qcom,calibration-variant Device Tree
property and add more infrastructure for the IPQ5332 platform.
Other than that, just an assortment of cleanups and minor bug fixes across
the "ath" family of drivers that aren't urgent enough to go through the
"current" process.
==================
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
gro_cells_receive() reports SKB_DROP_REASON_NOT_SPECIFIED when the device
is down or the GRO cell queue length exceeds max_backlog.
Pass SKB_DROP_REASON_DEV_READY and SKB_DROP_REASON_CPU_BACKLOG to
kfree_skb_reason() for these two cases, respectively.
Suggested-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260916091420.138170-1-xuanqiang.luo@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Javen Xu says:
====================
add support for phy chip and firmware
This series patch add support forRTL8261CE_CG and RTL8261D_VM, and add
firmware support for RTL8261D.
====================
Link: https://patch.msgid.link/20260916081444.497-1-javen_xu@realsil.com.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
