axienet_probe() reads its configuration exclusively through the of_*
API, so the driver can only be instantiated from a device tree node.
The ADVA TimeCard X2 is a PCIe timing card, driven by ptp_ocp, whose
FPGA contains an AXI Ethernet MAC with an AXI DMA engine. ptp_ocp is
going to register the MAC as a child platform device described by a
software node, so that this driver runs it rather than a copy in
ptp_ocp. That needs the probe-time configuration to be readable from a
software node.
Convert only the lookups such a caller needs: "xlnx,rxmem", which probe
requires; "phy-mode"; the MAC address; and the PHY connection, which is
where phylink finds a "fixed-link" child. On a device tree this is a
no-op: device_property_read_u32() dispatches to the of_* implementation
when dev->fwnode is an OF node, phylink_of_phy_connect() is a wrapper
around phylink_fwnode_phy_connect(), and device_get_phy_mode() and
device_get_mac_address() are thin fwnode wrappers around the same
lookups. device_get_mac_address() also keeps the "mac-address" nvmem
cell fallback that of_get_mac_address() has.
Note that device_get_phy_mode() returns the mode as a positive value
rather than through an out parameter, so the error test changes from
"if (ret)" to "if (ret < 0)".
Everything else stays on the OF API. "xlnx,txcsum", "xlnx,rxcsum" and
"xlnx,switch-x-sgmii" are optional, and "xlnx,phy-type" is deprecated in
favour of "phy-mode". Without an OF node each of those lookups finds
nothing, exactly as for a device tree node that leaves them out: no
checksum offload, no runtime SGMII/1000BASE-X switching and a
fall-through to "phy-mode". The "dmas" test likewise selects the
built-in AXI DMA engine. The "axistream-connected", "pcs-handle" and
"phy-handle" phandle lookups stay too: a caller without an OF node takes
neither branch, getting its DMA registers from its own platform
resources, and it cannot use the SGMII and 1000BASE-X modes, which need
a PCS.
No functional change intended.
Tested on the X2 with a local ptp_ocp change, with CONFIG_OF disabled
and enabled: the interface probes with its configuration read from the
software node and passes traffic. No device tree board was available,
so the claim that this is a no-op for device tree users rests on the
dispatch described above.
Assisted-by: LLM sparse
Signed-off-by: Sagi Maimon <maimon.sagi@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Suraj Gupta <suraj.gupta2@amd.com>
Reviewed-by: Suraj Gupta <suraj.gupta2@amd.com>
Link: https://patch.msgid.link/20260928074256.462345-2-maimon.sagi@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Quanye Yang says:
====================
tcp: annotate lockless access to sk->sk_err
do_recvmmsg() and getsockopt(SO_ERROR) call sock_error() without the
socket lock and clear sk_err with xchg().
Patch 1 covers TCP. Peek-only sites use READ_ONCE(). On the no-data
recv and splice paths, call sock_error() once and only stop when it
returns a non-zero error. tcp_bpf_sendmsg() folds two unmarked loads
into one READ_ONCE() and uses that value as the returned errno.
Patch 2 does the same for MPTCP and annotates the remaining subflow
error-report peeks.
====================
Link: https://patch.msgid.link/20260925-mptcp-sk-err-net-v5-0-0cac04d6ea48@proton.me
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
sock_error() can clear sk_err with xchg() without the socket lock.
On the no-data msk recv and splice paths, call sock_error() once and
only stop when it returns a non-zero error. Annotate the remaining
msk send and subflow error-report peeks with READ_ONCE().
Signed-off-by: Quanye Yang <quanyeyang@proton.me>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260925-mptcp-sk-err-net-v5-2-0cac04d6ea48@proton.me
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
BUG: KCSAN: data-race in do_recvmmsg / mptcp_recvmsg
read-write (marked) to 0xffff8880134d391c of 4 bytes by task 2619 on cpu 1:
instrument_atomic_read_write include/linux/instrumented.h:113 [inline]
sock_error include/net/sock.h:2565 [inline]
do_recvmmsg+0x50c/0x580 net/socket.c:3049
__sys_recvmmsg net/socket.c:3144 [inline]
__do_sys_recvmmsg net/socket.c:3167 [inline]
__se_sys_recvmmsg net/socket.c:3160 [inline]
__x64_sys_recvmmsg+0x161/0x180 net/socket.c:3160
x64_sys_call+0x19c7/0x1ca0 arch/x86/include/generated/asm/syscalls_64.h:300
do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
do_syscall_64+0xde/0x3d0 arch/x86/entry/syscall_64.c:84
entry_SYSCALL_64_after_hwframe+0x77/0x7f
read to 0xffff8880134d391c of 4 bytes by task 2620 on cpu 0:
tcp_recv_should_stop include/net/tcp.h:3086 [inline]
mptcp_recvmsg+0x54d/0xd50 net/mptcp/protocol.c:2466
inet_recvmsg+0x204/0x210 net/ipv4/af_inet.c:894
sock_recvmsg_nosec net/socket.c:1151 [inline]
sock_recvmsg+0x11a/0x140 net/socket.c:1173
____sys_recvmsg+0x14b/0x3c0 net/socket.c:2933
___sys_recvmsg+0x116/0x160 net/socket.c:2975
__sys_recvmsg net/socket.c:3008 [inline]
__do_sys_recvmsg net/socket.c:3014 [inline]
__se_sys_recvmsg net/socket.c:3011 [inline]
__x64_sys_recvmsg+0xeb/0x160 net/socket.c:3011
x64_sys_call+0x1319/0x1ca0 arch/x86/include/generated/asm/syscalls_64.h:48
do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
do_syscall_64+0xde/0x3d0 arch/x86/entry/syscall_64.c:84
entry_SYSCALL_64_after_hwframe+0x77/0x7f
value changed: 0x0000006b -> 0x00000000
Reported by Kernel Concurrency Sanitizer on:
CPU: 0 UID: 0 PID: 2620 Comm: syz.2.33 Not tainted 7.2.0-g39d4f32c5d53 #76 PREEMPT(full)
Hardware name: QEMU Ubuntu 26.04 PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1ubuntu1 04/01/2014
do_recvmmsg() and getsockopt(SO_ERROR) call sock_error() without the
socket lock. sock_error() clears sk_err with xchg(), which races with
unmarked loads of the same field.
KCSAN reported the unmarked peek in tcp_recv_should_stop(). Annotate
that helper and the other send-side peeks with READ_ONCE().
On the no-data recv and splice paths, if (sk_err) followed by
sock_error() and an unconditional break can return 0 after another
thread consumes the error. Call sock_error() once and only stop when
it returns a non-zero error.
tcp_bpf_sendmsg() read sk_err twice; fold those unmarked loads into
one READ_ONCE() and use that value as the returned errno. The field
is still not consumed.
MPTCP is handled in the next patch.
Suggested-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Link: https://lore.kernel.org/netdev/8bbee583-6f21-4817-bfeb-2d60057380a3@linux.dev/
Reported-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/632
Signed-off-by: Quanye Yang <quanyeyang@proton.me>
Reviewed-by: Eric Dumazet <edumazet@kernel.org>
Link: https://patch.msgid.link/20260925-mptcp-sk-err-net-v5-1-0cac04d6ea48@proton.me
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Jakub Kicinski says:
====================
net: move the type 2 sockets out of tree
LLC2 sockets are admin-only already. We have been getting a trickle
of LLM-driven fixes for these, even tho we don't know of any active
user. The code is so bad the LLM fixes just turn into a never ending
stream of revisions and follow ups as fixing one condition reveals
5 more bugs. Let's move this code out of tree.
The series itself is LLM generated, the LLM was also nice enough
to generates some tests and validate that the OOT module actually
works.
====================
Link: https://patch.msgid.link/20260928190800.2521749-1-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The bridge and the openvswitch code include <net/llc.h>,
<net/llc_pdu.h> and <linux/llc.h> without using anything out of them.
parse_ethertype() is the one exception: it wants LLC_SAP_SNAP, which
comes from the uAPI header <linux/llc.h> pulls in, so flow.c keeps
that one. The LLC core has leftovers of its own - slab, string,
interrupt and net_namespace - which it has not used in a long time.
None of this is new, the type 2 removal has just shrunk the LLC
headers enough to make it easy to see.
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Acked-by: Aaron Conole <aconole@redhat.com>
Link: https://patch.msgid.link/20260928190800.2521749-4-kuba@kernel.org
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Nothing in tree registers the type 1 / type 2 packet handlers or the
station handler any more, and nothing looks at the socket hashes
hanging off struct llc_sap. The two SAPs opened in tree - SNAP, and STP
for the bridge's BPDUs and GARP's PDUs - receive through the per-SAP
rcv_func(), so llc_rcv() boils down to a SAP lookup and a call.
llc_sap_list becomes static and five exports go away with all this; the
llc2 module out of tree has been reworked to open its own SAPs.
Frames with a NULL DSAP used to be handed to the station handler
before the SAP lookup. They take the normal path now, meaning they get
dropped unless something registers SAP 0.
struct llc_sap is down to 48 bytes on 64-bit from over a kilobyte,
which also moves its GFP_ATOMIC allocation from kmalloc-2k to
kmalloc-64. The two 64-entry socket hashes are the bulk of it, and the
address it carried is now just the SAP number - nothing has read the
MAC half since the socket layer left.
llc_pdu.h keeps only what its remaining users need, plus LLC_PDU_RSP to
document the one argument which can take it. That takes out the type 2
(I and S format, FRMR) definitions, the XID and TEST builders with
their constants - the kernel neither sends nor answers either any more
- the SAP address defines, the field accessors, and the prototypes of
the llc_pdu.c helpers which went out of tree with the rest of LLC2.
With the I and S formats gone llc_pdu_header_init() has one PDU type
left, so drop the argument.
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Link: https://patch.msgid.link/20260928190800.2521749-3-kuba@kernel.org
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
802.2 LLC is only used in tree by protocols which need the
connectionless type 1 subset: STP, which carries the bridge's BPDUs,
GARP, which sends its own UI PDUs, and SNAP. The llc2 module on top of
the core - the type 2 connection state machine, the type 1 SAP state
machine, the station component and the PF_LLC socket family - has no
in-kernel users and nobody who can test it; what we get instead is a
slow trickle of drive-by fixes.
There was a recent patch from Ernestas Kulik indicating potential
real life use, but it was new/experimental and that person is
not responding to off-list pings.
Let LLC2 follow AX.25, hamradio and AppleTalk out of the Linux tree.
We will maintain the code at: github.com/linux-netdev/mod-orphan
for anyone interested in playing with it.
PF_LLC goes in full, both the class two SOCK_STREAM and the class one
SOCK_DGRAM half, and so do /proc/net/llc/ and /proc/sys/net/llc/. Note
that the kernel also stops answering XID and TEST commands, addressed
to a SAP or to the station - those are type 1, but they lived in the
module, and they got answered whether or not any socket was open.
Nothing in tree asks for them; what the core keeps is SAP registration
and the UI path the in-tree users need.
Retain the uAPI for now, like we did for AppleTalk. Only the socket ABI
half of it is vestigial: STP, GARP, the bridge and openvswitch use the
SAP numbers it defines. Cleaning up what the core no longer needs
follows in the next patch.
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Link: https://patch.msgid.link/20260928190800.2521749-2-kuba@kernel.org
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Manish Awasthi says:
====================
net: mana: Add support for the CDX bus
This series adds CDX bus support to the MANA driver.
The shared GDMA and Ethernet code currently builds together with the PCI
transport. To add another bus without duplicating the driver or adding
configuration checks throughout the shared code, this series separates the
bus-specific operations and builds each transport independently.
Patch 1 introduces gdma_bus_ops and routes bus-specific interrupt, reset,
service, and setup operations through it.
Patch 2 moves the PCI-specific code from gdma_main.c into gdma_pci.c
without changing PCI behavior.
Patch 3 builds the shared code as gdma_core.ko and the PCI transport as
mana.ko. The PCI module keeps its existing name, device table, and
mana.eth/mana.rdma auxiliary-device identities.
Patch 4 adds the CDX transport as mana_cdx.ko for device ID 0x00C2.
====================
Link: https://patch.msgid.link/20260924173054.589291-1-mawasthi@linux.microsoft.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add the CDX transport as mana_cdx.ko for device ID 0x00C2, using the shared
gdma_core.ko. Allocate interrupts at probe, limit queues to available
vectors, use 32-bit DMA, and keep CDX auxiliary devices separate from PCI.
Signed-off-by: Manish Awasthi <mawasthi@linux.microsoft.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Link: https://patch.msgid.link/20260924173054.589291-5-mawasthi@linux.microsoft.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Build the shared GDMA and Ethernet code as gdma_core.ko, selected by
MICROSOFT_GDMA_CORE. Build the PCI transport separately as mana.ko and
export the required core symbols.
Preserve the PCI module name, device table, and mana.eth/mana.rdma
auxiliary-device names. Each transport registers its own bus driver.
Signed-off-by: Manish Awasthi <mawasthi@linux.microsoft.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Link: https://patch.msgid.link/20260924173054.589291-4-mawasthi@linux.microsoft.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Move PCI transport code and driver callbacks from gdma_main.c into
gdma_pci.c. Keep shared IRQ bookkeeping in the core and update build
wiring.
Signed-off-by: Manish Awasthi <mawasthi@linux.microsoft.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Link: https://patch.msgid.link/20260924173054.589291-3-mawasthi@linux.microsoft.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Introduce per-device gdma_bus_ops for interrupt allocation, IRQ lookup,
reset, servicing, and bus-specific capabilities. Route the shared GDMA
code through these callbacks and provide the PCI implementation.
Move common device bring-up and teardown into mana_gd_setup() and
mana_gd_cleanup(), including hardware-channel initialization, device
enumeration, interrupt-pool sizing, and servicing workqueue management.
Record the vPort count for transport-specific queue sizing and keep shared
IRQ context bookkeeping in the core.
This prepares the driver for additional bus transports without duplicating
the core or adding configuration checks throughout it.
Signed-off-by: Manish Awasthi <mawasthi@linux.microsoft.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Link: https://patch.msgid.link/20260924173054.589291-2-mawasthi@linux.microsoft.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
SMC transmit work is queued without holding a socket reference. After
an active close has cancelled tx_work, a received CDC message can queue
it again while the socket is in SMC_PEERCLOSEWAIT1. Passive close can
then reach SMC_CLOSED, call smc_conn_free() and drop the last socket
reference before smc_tx_work() acquires the socket lock. The worker
then accesses the freed socket.
KASAN reported:
BUG: KASAN: slab-use-after-free in lock_sock_nested+0x97/0x180
Write of size 8 by task kworker/0:1/11
Workqueue: smc_tx_wq-00000000 smc_tx_work
Call Trace:
lock_sock_nested+0x97/0x180
smc_tx_work+0x5d/0x170
process_one_work+0x5ce/0xeb0
worker_thread+0x45b/0xd10
Allocated by task 24:
sk_prot_alloc+0x56/0x210
sk_alloc+0x2b/0x6f0
smc_tcp_listen_work+0x16d/0xfc0
Freed by task 182:
slab_free_after_rcu_debug+0xa6/0x1e0
rcu_core+0x509/0x1850
Hold a socket reference for each successful enqueue and release it when
the worker finishes or a pending invocation is cancelled. Cover all three
queue sites and all cancellation sites, including the socket options.
Check conn->freed in smc_tx_pending() under the socket lock: retaining the
socket does not retain connection resources released by smc_conn_free().
This also covers pending transmit processing from smc_release_cb().
Use queue_delayed_work() for the busy-slot retry as well. All tx_work
delays are zero, so an already queued invocation needs no timer update.
Unlike mod_delayed_work(), its return value distinguishes a successful
enqueue from work disabled temporarily by cancel_delayed_work_sync(),
allowing the extra reference to be returned when no work was queued.
Cc: stable+noautosel@kernel.org # LLM report + LLM fix, not seen in real life
Fixes: e6727f3900 ("smc: send data (through RDMA)")
Link: https://lists.openwall.net/netdev/2026/09/09/105
Signed-off-by: Chengfeng Ye <nicoyip.dev@gmail.com>
Link: https://patch.msgid.link/20260927075120.3695060-1-nicoyip.dev@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Sashiko reported [1] that 'Missing __GFP_ZERO in folio_alloc() causes
uninitialized kernel memory to be exposed in the receive message buffer'.
An ism dmb is receive-only, so the data is not leaked to a remote peer.
In general the smc kernel module (dibs client) will only push newly
received data to userspace. We still should not have uninitialized data
in a receive buffer.
Since
commit 750afb08ca ("cross-tree: phase out dma_zalloc_coherent()")
dma_alloc_coherent no longer required the __GFP_ZERO flag, but when
commit 83781384a9 ("s390/ism: Properly fix receive message buffer allocation")
switched to folio_alloc(), it should have added back the __GFP_ZERO flag.
Add __GFP_ZERO flag and state in dibs.h that register_dbm() provides
a zerorized buffer (dibs_lo already does).
Link: https://lore.kernel.org/linux-s390/20260903143746.A5CC41F00A3A@smtp.kernel.org/ [1]
Fixes: 83781384a9 ("s390/ism: Properly fix receive message buffer allocation")
Signed-off-by: Alexandra Winter <wintera@linux.ibm.com>
Reviewed-by: Julian Ruess <julianr@linux.ibm.com>
Link: https://patch.msgid.link/20260928151420.383105-1-wintera@linux.ibm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Björn Töpel says:
====================
fbnic: Support larger RX pages
This series adds support for large io_uring zero-copy RX buffers to
fbnic.
fbnic hardware consumes receive memory in 4 KiB device pages, while
io_uring may expose a larger software buffer, such as 256 KiB. Track
the device-page geometry per BDQ, represent each large buffer with
consecutive descriptors, and decode completions to the corresponding
offset within the buffer. HPQ keeps its existing PAGE_SIZE geometry.
Larger buffers also reduce pressure on the memory provider. One
provider allocation supplies multiple 4 KiB device pages, so the same
amount of receive memory needs fewer net_iov objects and fewer
allocation, refill, and recycle operations. Hardware descriptor use
remains unchanged.
Ring depth and buffer size must be validated together. An ethtool ring
change can otherwise make an active memory-provider configuration
invalid. Store RX ring depths in netdev_config, stage proposed values
in cfg_pending, and validate the default and each RX queue before
committing the change. Both netlink and ioctl use the same transaction
helpers.
The selftest requests a power-of-two buffer larger than twice the MTU,
checks the reported buffer length, and verifies received data. It does
not assume how packets are placed within the buffer.
====================
Link: https://patch.msgid.link/20260925104417.2325213-1-bjorn@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The large-chunk test always requests two base pages. On interfaces with
a large MTU, that may not exceed two maximum-sized frames.
Request a power-of-two buffer larger than twice the MTU. This makes the
existing rx_buf_len check and data-integrity traffic exercise the larger
layout.
Signed-off-by: Björn Töpel <bjorn@kernel.org>
Tested-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260925104417.2325213-6-bjorn@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Memory providers can set the receive page size for a queue through
QCFG_RX_PAGE_SIZE. fbnic creates PAGE_SIZE PPQ page-pool allocations,
so larger rx_buf_len values are not reflected in the PPQ BDQ geometry.
Use the rendered rx_page_size for PPQ allocations and completion
decoding. The NIC still consumes 4 KiB device pages; a larger PPQ page
is represented by consecutive device-page descriptors, and completion
IDs decode to offsets within the same netmem allocation.
Validate rx_page_size against fbnic's fragment-reference budget,
device-page geometry, and rendered PPQ depth. The page size must be a
power-of-two of at least one device page, its worst-case payload
fragment count must fit the page-pool reference bias, and the PPQ must
retain usable software depth after expansion.
Signed-off-by: Björn Töpel <bjorn@kernel.org>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260925104417.2325213-5-bjorn@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Memory-provider queue configuration is validated when the provider is
bound. A later ethtool ring change may invalidate it because drivers
can size queue memory from both ring depth and RX page size. The fbnic
consumer is added in the following patch.
Keep configured RX ring depths in netdev_config and stage proposed
values in cfg_pending. Validate every RX queue before calling the
driver. Each check validates the device defaults, then any queue
memory-provider override. Commit the values only after the driver
accepts them.
Drivers which consume stored ring depths through queue configuration
must initialize every RX depth before registering the netdev. Stored
values override callback defaults, including when zero.
The callback receives a rendered configuration rather than a queue ID.
Validation should depend on the configuration, not queue identity.
Checking defaults also covers the case where every queue has a
memory-provider override.
Drivers may normalize ring depths when applying them. Require the
validation callback to use the same normalization. Drivers must report
the applied depths through the ethtool_ringparam argument so the core
records the result.
Use the same transaction for ioctl and netlink. Drivers without
ndo_validate_qcfg skip the new validation.
Link: https://lore.kernel.org/all/20250421222827.283737-14-kuba@kernel.org/
Signed-off-by: Björn Töpel <bjorn@kernel.org>
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Joe Damato <joe@dama.to>
Link: https://patch.msgid.link/20260925104417.2325213-4-bjorn@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
fbnic derives the BDQ buffer layout from PAGE_SIZE. That decides at
build time how a posted page is split into 4 KiB device pages, and
uses the same completion decoding for HPQ and PPQ. That is wrong once
the queues use different posted-page sizes; completions must be
decoded with the geometry of the queue that produced them.
Keep PAGE_SIZE as the posted-page size for both queues in this change,
so the descriptor format and runtime behavior stay unchanged.
Signed-off-by: Björn Töpel <bjorn@kernel.org>
Reviewed-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Joe Damato <joe@dama.to>
Link: https://patch.msgid.link/20260925104417.2325213-3-bjorn@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
netdev_config manipulation will become slightly more complicated
soon and will be used by both ethtool and the queue API.
Encapsulate the logic in helper functions.
Signed-off-by: Björn Töpel <bjorn@kernel.org>
Reviewed-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Joe Damato <joe@dama.to>
Link: https://patch.msgid.link/20260925104417.2325213-2-bjorn@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Bastien Curutchet says:
====================
net: dsa: microchip: add periodic output support for the KSZ8463
This series aims to add periodic output support for the KSZ8463.
The way the KSZ8463 handles periodic output differs from that
of the other KSZ switches. It therefore needs its own set of
perout callbacks (configure, start, reset, enable, restart).
Patch 1 saves the full request to be able to retrieve all its
information in case of restart
Patches 2 to 4 prepare the driver to accept different kinds of periodic
output settings.
Patches 5 to 10 extract a set of functions from the existing periodic
output support that can be reused by the KSZ8463, avoiding code
duplication as much as possible.
Patch 11 adds periodic output support for the KSZ8463.
====================
Link: https://patch.msgid.link/20260925-ksz-perout-v4-0-d675bd21ce49@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
KSZ8463 has several periodic outputs. The way it handles them differ
from the other KSZ switches:
- KSZ8463 has one set of registers for each of its 12 units while others
switches share on set of configuration registers for all their units.
- Maximum size of the KSZ8463 pulse width is smaller
- KSZ8463 has 12 outputs while others only have 2
Add support for the KSZ8463 periodics outputs through a set of KSZ8463
specific functions.
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260925-ksz-perout-v4-11-d675bd21ce49@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The KSZ8463 supports periodic outputs but doesn't handle them in the same
way as the other KSZ switches. To add proper support for the KSZ8463, a
dedicated ksz8463_ptp_adjtime() function needs to be created. This
function will access the same registers as the common ksz_ptp_adjtime()
function.
Extract the register accesses into a dedicated function so it can be
used later by the KSZ8463 support.
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260925-ksz-perout-v4-10-d675bd21ce49@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The KSZ8463 supports periodic outputs but doesn't handle them in the same
way as the other KSZ switches. To add proper support for the KSZ8463, a
dedicated ksz8463_ptp_settime() function needs to be created. This
function will access the same registers than the common
ksz_ptp_settime().
Extract the register accesses into a dedicated function so it can be
used later by the KSZ8463 support.
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260925-ksz-perout-v4-9-d675bd21ce49@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The KSZ8463 supports periodic outputs but doesn't handle them in the same
way as the other KSZ switches. To add proper support for the KSZ8463, a
dedicated ksz8463_ptp_restart_perout() function needs to be created. This
function will use the same request initialization as the common
ksz_ptp_restart_perout() function.
Extract the inialization into a dedicated function so it can be used
later by the KSZ8463 support.
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260925-ksz-perout-v4-8-d675bd21ce49@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The KSZ8463 supports periodic outputs but doesn't handle them in the same
way as the other KSZ switches. To add proper support for the KSZ8463, a
dedicated ksz8463_ptp_enable_perout() function needs to be created. This
function will use the same algorithm to compute the periodic cycles as
the common ksz_ptp_enable_perout() function.
Extract these algorithms into a dedicated function so they can be used
later by the KSZ8463 support.
Add some checks on the period to ensure the request is valid and will
not cause divide by zero issues if the periodic output is restarted.
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260925-ksz-perout-v4-7-d675bd21ce49@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The KSZ8463 supports periodic outputs but doesn't handle them in the same
way as the other KSZ switches. To add proper support for the KSZ8463, a
dedicated ksz8463_ptp_enable_perout() function needs to be created. This
function will use the same algorithm to select the output pin as the
common ksz_ptp_enable_perout() function.
Extract the pin selection algorithm into a dedicated function so it can
be used later by the KSZ8463 support.
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260925-ksz-perout-v4-6-d675bd21ce49@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
KSZ8463 also has periodic output capabilities but the way its outputs
are driven differs from the other switches. It will need its own set of
PTP callbacks to implements this behaviour.
Extract the PTP callbacks configuration in a dedicated function to be
called before the PTP registration to ease the use of others callbacks
when needed.
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260925-ksz-perout-v4-5-d675bd21ce49@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The pulse width validity is checked against an hardcoded mask. KSZ8463
uses a smaller register than other switches so this check won't work for
it.
Move the mask as a ksz_ptp_tou_pulse_verify()'s input to allow changing
it for KSZ8463 case.
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260925-ksz-perout-v4-4-d675bd21ce49@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The number of periodic signals available is hardcoded to 3 while
KSZ8463 can produce 12 different periodic signals.
Add an n_per_out attribute to the struct ksz_chip_data to make this
setting configurable.
Set it to 3 for all the PTP-capable switches.
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260925-ksz-perout-v4-3-d675bd21ce49@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The number of periodic output pins available is hardcoded to 2 while
KSZ8463 has 12 pins that can be used as periodic outputs.
Add an n_pin attribute to the struct ksz_chip_data to make this setting
configurable.
Set it to 2 for all the PTP-capable switches.
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260925-ksz-perout-v4-2-d675bd21ce49@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
When a periodic output is initialized, its period and start time are
stored to initialize it back in case of restart. These information
aren't enough if the request contains flags or targets a pin that isn't
the first output of the switch. At restarts, these two arguments are
always set to 0.
The 'flag issue' isn't concrete so far because the driver doesn't
advertise any .supported_perout_flags so any flag request gets rejected
by the upper layer.
I don't know if other switches use non-zero indexes but the KSZ8463 has
twelve periodic outputs, so this index has to also be saved from now on.
Save the full request when a periodic output is successfully started.
Use the saved request when the periodic output is restarted.
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260925-ksz-perout-v4-1-d675bd21ce49@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
stmmac_tso_xmit() fills the MSS context descriptor and stores the new MSS
in tx_q->mss right away, but the descriptor only gets its OWN bit much
later, right before the frame is handed to the DMA. Every error path in
between - the dma_map_single() of the linear part and the
skb_frag_dma_map() of each fragment - returns with tx_q->mss already
updated while the MAC is still programmed with the previous MSS.
The context descriptor is now handled like the data descriptors are:
tx_q->cur_tx is not advanced while it is being filled, so the slot stays
where the next transmit fills it, and the error paths release it
explicitly instead of leaving a descriptor the DMA will stop on in the
middle of the ring. With the queue no longer wedged by that descriptor,
the stale cached MSS is what remains: the next skb carrying the same
gso_size compares equal to the cached value, no context descriptor is
emitted, and the hardware segments the TCP stream with the MSS of an
earlier frame, generating frames whose payload size does not match what
the stack accounted for.
Drop the cached value on those paths instead. Zero is what
stmmac_reset_tx_queue() leaves behind, so the next TSO frame programs the
context descriptor again.
The store itself stays ahead of the mappings, as before, rather than
moving next to the OWN bit: stmmac_tx_err() reinitialises the channel and
clears tx_q->mss from the DMA interrupt handler, which takes no TX queue
lock, so it can run in the middle of stmmac_tso_xmit(). Publishing the
cache after the descriptor has been handed over would widen the window in
which such a reset is overwritten with an MSS that the reinitialised
channel was never programmed with.
Found by manual code inspection and AI tools.
Not triggered or tested on real hardware.
Cc: stable+noautosel@kernel.org # untested fix to unlikely driver error path
Fixes: f748be531d ("stmmac: support new GMAC4")
Signed-off-by: Linkui Xiao <xiaolinkui@kylinos.cn>
Link: https://patch.msgid.link/20260928123422.1698785-1-xiaolinkui@126.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
smc_llc_link_active() marks a link active before scheduling its testlink
work. The first-link confirmation paths call it without llc_conf_mutex,
allowing link-down processing to clear the link between these operations:
Connection setup Link-down worker
smc_llc_link_active()
link->state = SMC_LNK_ACTIVE
smcr_link_clear()
link->clearing = 1
smc_llc_link_clear()
cancel_delayed_work_sync()
schedule_delayed_work()
The connection reference keeps the link alive during activation, but the
newly queued work outlives that reference. Later cleanup skips clearing
an already-clearing link, leaving its timer armed when the link group is
freed. KASAN reported:
BUG: KASAN: use-after-free in __run_timers+0x723/0x8d0
Write of size 8 at addr ffff88810f108810 by task swapper/1/0
Call Trace:
__run_timers+0x723/0x8d0
timer_expire_remote+0xd3/0x120
tmigr_handle_remote_up+0x4f4/0xab0
__walk_groups_from+0x40/0x150
tmigr_handle_remote+0x229/0x2c0
run_timer_softirq+0x1f5/0x250
Hold llc_conf_mutex around first-link activation on both sides so that
link-down processing cannot cancel the work before it is queued. Also
protect the client's initial optional add-link processing, which can
activate a second link without the lock. The other add-link paths already
hold llc_conf_mutex. This serializes every activation with link teardown
without changing the handshake sequence or error handling.
Signed-off-by: Chengfeng Ye <nicoyip.dev@gmail.com>
Link: https://patch.msgid.link/20260927074547.3694742-1-nicoyip.dev@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
__netpoll_send_skb() parks an skb on npinfo->txq whenever the device
cannot take it at once, and once the queue is non-empty every later skb
goes straight there to keep ordering. queue_process() drains it from a
workqueue and, unlike the direct path, never polls the device for
completions: when the ring is stopped it backs off HZ/10. Nothing limits
the queue length.
A producer that outruns that drain therefore grows the queue until the
host is out of memory. Observed with netconsole forwarding a GPU driver
that logged one line at ~1e5/s after a firmware hang. The NIC was
moving ~17k packets/s: completions for each burst surfaced tens of ms
later, outside the one-tick window, so queue_process() slept HZ/10 per
ring while ~1e5 lines/s kept arriving. The queue grew at ~170 MB/s,
unreclaimable slab reached 51 GiB in five minutes and the OOM killer
ran from kswapd with 341 MiB of anonymous memory on the whole box. What
the queue held was the flood itself; the OOM report never left the
host.
Reproduced on the same host (netconsole over a 10G ConnectX-4 Lx) under
the same slow-completion condition: 200k lines to /dev/kmsg in 0.12 s
grew unreclaimable slab by 173 MiB, about 188k skbs, draining at
~8-10k packets/s. With prompt completions the same burst drains at line
rate; a stall on the link while lines keep arriving faster than the
drain reproduces the growth.
Until the 2006 netpoll rework [1] the deferred path drained through
dev_queue_xmit(), with the stack's own backpressure, and was capped at
16 skbs (MAX_QUEUE_DEPTH). That series moved it to a direct
hard_start_xmit() with the HZ/10 back-off and made the queue
per-device, dropping the cap on the way.
Cap it at 1024 skbs per device and drop new skbs beyond that. The drop
is counted in tx_dropped of the device whose queue is full and freed
with SKB_DROP_REASON_FULL_RING. A netconsole target bound directly to
that device also gets NET_XMIT_DROP and, with CONFIG_NETCONSOLE_DYNAMIC,
counts it in xmit_drop_count. When a stacked device (bond, bridge,
team, vlan, macvlan) passes the skb down and the lower device's queue
is the one that fills, the return value does not reach netconsole and
the lower device's tx_dropped is the record. The bound holds either
way. Nothing is logged on the drop path because that would recurse
into the console being drained.
[1] https://lore.kernel.org/netdev/20061026225645.482978803@osdl.org/
Signed-off-by: Zack Gomez <zack.gomez@gmail.com>
Reviewed-by: Breno Leitao <leitao@debian.org>
Link: https://patch.msgid.link/20260925204537.2664119-1-zack.gomez@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
When retrieving the MAC address, ax88172a_bind() checks the return
value of asix_read_cmd() against ETH_ALEN to detect short reads.
Commit c28d9a2856 ("ax88172a: fix ax88172a_unbind() failures") added
an -EIO assignment to ensure that this failure path returns a negative
error code, even when asix_read_cmd() returns a non-negative short-read
length.
Short-read handling was subsequently added to asix_read_cmd() by commit
920a9fa27e ("net: asix: add proper error handling of usb read errors").
The helper now converts short reads to -ENODATA while preserving
negative errors from the underlying USB read operation.
The MAC address short-read check in ax88172a_bind() is therefore
redundant now, and overwriting the return value with -EIO is no longer
necessary to ensure that the failure path returns a negative error code.
Check only for negative return values and remove the -EIO assignment
to preserve the error returned by asix_read_cmd() through the existing
cleanup path.
Signed-off-by: Xinsheng Zhu <xinsheng.zhu.ny@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260928044011.63926-1-xinsheng.zhu.ny@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The L2 encapsulation modes of the seg6 lwtunnel reallocate the skb head
on every packet, where the IPv6 encapsulation modes reallocate only when
they have to. Ask for the whole encapsulation up front instead, so that
the reallocation happens at most once and only when the headroom really
is too small:
skb->mac_len + sizeof(struct ipv6hdr) + ipv6_optlen(tinfo->srh)
+ dst_dev_overhead(cache_dst, skb)
__seg6_do_srh_encap() then finds the room it needs and its own
skb_cow_head() becomes a no-op.
Drivers reserve more than that on the forwarding path, so the
reallocation usually disappears altogether. A single-segment policy
on ixgbe needs
14 (mac_len) + 40 (ipv6hdr) + 24 (SRH) + 16 (LL_RESERVED_SPACE) = 94
against the 206 bytes the driver leaves. Where the headroom is
smaller, as on a veth pair, pskb_expand_head() is called once per
forwarded packet instead of twice. Asking only for skb->mac_len would
still take two whenever the skb is header-cloned, because the cow that
unclones it does not also make room for the outer header.
The cost is amplified by CONFIG_INIT_ON_ALLOC_DEFAULT_ON, which many
distributions enable: every new head is zeroed in full, and that memset
alone accounts for 16% of the datapath profile.
Throughput at 0.5% packet loss, 64-byte frames forwarded through one
2.30 GHz core (Xeon E5-2650 v3, ixgbe 82599ES), offered by TRex and
binary-searched over 10 runs of 10 s:
Before: 654.6 kpps
After: 965.7 kpps
Signed-off-by: Yuya Kusakabe <yuya.kusakabe@gmail.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Link: https://patch.msgid.link/20260925-seg6-l2cow-v3-1-fc83821542a7@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
- ath10k: NVMEM device tree bindings
- ath12k: QMI firmware alignments
- mm81x: AP improvements
- mac80211:
- CIP (control frame integrity) support
- NAN improvements
- cfg80211:
- improvements for AP regulatory checks
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEpeA8sTs3M8SN2hR410qiO8sPaAAFAmq9A3UACgkQ10qiO8sP
aABm0g//QomwpMdiwQifQ7Im/a4BN/adDZ5u05oHs8wXIX9jVImgWVnrFFc9BjfH
+sqY8gAKIMJKsqguljqagcdvITBdJJKWkLf01uOwPR1uQPaFMOuzIJocoAJoSrnp
mIAoMxHuUZ2Aw9CE1NyrHo6FiRZF0o0vaIDfCRDBVC1qb1Z5HfGSLuSjuYC6z130
DhrZ0JAnhP3YPGv2qFMSbtmdzoML2R4KHpUg0Cp8slrahoGsFkTH4rvqyiGa5mXC
ICUwHmRgvr0a0cVUlGOEJh63ztgQxKTMUfP9THBPpL5R92YFrQRB90zE8NB7Kf0D
izZEYv++FVXR/lGnn1ka7SViOp9Sual/7v1lQRX+gr9VuXvspeUu0YnsEzbu8/QY
0QVrs7+o+2vJRH8muL/dqE0SBHQneM5nIXhDeAIIA+2kD+KpHocRrMUnxSiXWAFJ
/FjNkZfv0fHGAa4lYKq43Wisps3errKF2WuIKp+Wbv1Ej1czGsfb0b77ETEwZmNM
awvvbDbP+q/CmOtL6v4rOZ2K52pqaX2f2T55fLbjuM/P3hNjbxN5eTIaxrzfd/U0
ONrpo8tBFhe8NQDk8lobLwAAyW/kgiIbkf4eYsraLxK7ejJj6Kvr17fNjWLzxBok
71VQ7Mu6DVS0aN6J76AIRBRBMeDGyUF2zBVP8BCa3IuZxks4SyU=
=wiFU
-----END PGP SIGNATURE-----
Merge tag 'wireless-next-2026-09-30' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next
Johannes Berg says:
====================
More features:
- ath10k: NVMEM device tree bindings
- ath12k: QMI firmware alignments
- mm81x: AP improvements
- mac80211:
- CIP (control frame integrity) support
- NAN improvements
- cfg80211:
- improvements for AP regulatory checks
* tag 'wireless-next-2026-09-30' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (67 commits)
wifi: mac80211: Gracefully deauthenticate on association timeout
wifi: libertas: fix RX OOB access from device-controlled pkt_ptr
wifi: mwifiex: Reattach interfaces on suspend failure
wifi: b43legacy: work around stack frame size warning
wifi: cw1200: fix link_id_db OOB access via device-controlled link ID
wifi: mwifiex: bound SDIO fw dump count by memory table size
wifi: mac80211: start next ROC after purging an interface
wifi: mac80211: fix potential ack-skb leak on error path
wifi: mac80211: mesh: don't send peering close in listen
wifi: mac80211_hwsim: Support NAN deferred schedule completion
wifi: mac80211: Restrict probe request rates for minimal content
wifi: nl80211: allow a NAN peer schedule with 2 channels in the same slot
wifi: cfg80211: use sysfs_emit_at() in addresses_show
wifi: cfg80211: require zero terminator in valid_regdb country table
wifi: cfg80211: fix NAN local schedule update ordering and allocation
wifi: mac80211: Fix a race when expiring a mesh path
wifi: cfg80211: validate monitor channel set against radio usage
wifi: nl80211: reject color-change requests that change 6 GHz power type
wifi: nl80211: defer AP beacon regulatory check to start_ap
wifi: radiotap: add definitions for UHR U-SIG
...
====================
Link: https://patch.msgid.link/20260930124547.228697-29-johannes@sipsolutions.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Przemek Kitszel says:
====================
ice: fix stats array overflow via proper realloc
Fix OOB access to the stats arrays.
The first commit (new in v5) fixes stats code against VSI_CHNL case (ADQ).
Next three commits are simple refactors to make the rest smaller,
the fifth one untangles the logic/lifetime of the stats array entries,
then we have the final fix for OOB access to the stats array (combined
for both PF and VF VSIs.
====================
Link: https://patch.msgid.link/20260925132636.123300-1-przemyslaw.kitszel@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The ring stats arrays were sized in one place and indexed in another,
with nothing reconciling the two. ice_vsi_alloc_stat_arrays() gave up as
soon as a container existed:
if (pf->vsi_stats[vsi->idx])
/* realloc will happen in rebuild path */
return 0;
while ice_vsi_alloc_ring_stats() walks the arrays with
ice_for_each_alloc_txq() / ice_for_each_alloc_rxq(), that is, up to
vsi->alloc_txq / vsi->alloc_rxq. Whenever the arrays are shorter than
the count ice_vsi_set_num_qs() ends up computing, that loop reads and
stores past the end of the kmalloc'ed pointer arrays.
Deferring to "the rebuild path" does not hold. It cannot get the size
right, and some paths never call it at all.
ice_devlink_reinit_down() is one of the latter. It calls ice_vsi_decfg()
directly, which does not free pf->vsi_stats[], and nothing on the way
down releases the main VSI's entry either: ice_dealloc_vsis() runs only
from ice_init()/ice_deinit(), and the single entry that ice_unload()
does drop is the control VSI's, via ice_deinit_fdir(). The main VSI's
arrays therefore survive the reload, while ice_devlink_reinit_up() runs
ice_vsi_cfg() and recomputes the count from
netif_get_num_default_rss_queues(), which follows cpu_online_mask.
Sizing the arrays with most CPUs offline and then onlining them is
enough, no VF involved:
for c in /sys/devices/system/cpu/cpu[0-9]*/online; do echo 0 > $c; done
echo 0000:18:00.0 > /sys/bus/pci/drivers/ice/unbind
echo 0000:18:00.0 > /sys/bus/pci/drivers/ice/bind
for c in /sys/devices/system/cpu/cpu[0-9]*/online; do echo 1 > $c; done
devlink dev reload pci/0000:18:00.0 action driver_reinit
The unbind/bind is what makes the arrays actually be allocated at the
small size; a reload alone only reuses them.
The read then runs off the end of tx_ring_stats[] and picks up whatever
follows it in kmalloc-32. Here that was a string, 0x74756f5f6c697475
spelling "util_out" in memory order. It is stored into ring->ring_stats
and faults on the first dereference, in ice_setup_tx_ring(), call trace:
RIP: 0010:ice_setup_tx_ring+0x8d/0xe0 [ice]
ice_vsi_setup_tx_rings+0x2a/0x80 [ice]
ice_vsi_open+0x28/0x170 [ice]
ice_open_internal+0xc9/0x160 [ice]
__dev_open+0x138/0x2b0
__dev_change_flags+0x1d5/0x250
netif_change_flags+0x21/0x60
do_setlink.constprop.0+0x336/0xcf0
rtnl_newlink+0x4a4/0x9b0
Even where the rebuild path does run, it sizes the arrays before
ice_vsi_decfg() returns the queues to the PF pool, and for an
ICE_VSI_PF VSI with no explicit request it derives the count from that
shared pool. Nothing serializes it against the recount in
ice_vsi_set_num_qs(), so a concurrent release, say
"echo 0 > sriov_numvfs", leaves the final count larger than the arrays
that were already installed.
ice_vsi_alloc_stat_arrays() runs from ice_vsi_cfg_def(), right after
ice_vsi_alloc_def() called ice_vsi_set_num_qs(), so it is the first
place where the queue count is final. Make it the only authority: keep
the existing arrays when they are already long enough, and otherwise
grow them with ice_vsi_install_stat_arrays(), which carries the
surviving entries over. The check only forces a grow: while both arrays
are long enough they are kept, an oversized one being merely wasteful.
Once either is too short the whole container is replaced, and then the
other one follows the final count too, shrinking if that is what it
takes.
Michal Schmidt hit the same corruption through the VF path, where a
guest raises its queue count with VIRTCHNL_OP_REQUEST_QUEUES and the
following VF reset reconfigures the VSI with the larger count while the
old, shorter arrays are still installed:
BUG: KASAN: slab-out-of-bounds in ice_vsi_alloc_ring_stats+0x385/0x4a0 [ice]
Workqueue: ice ice_service_task [ice]
Call Trace:
kasan_report+0xd7/0x120
ice_vsi_alloc_ring_stats+0x385/0x4a0 [ice]
ice_vsi_cfg_def+0x12e2/0x2060 [ice]
ice_vsi_cfg+0xb5/0x3c0 [ice]
ice_reset_vf+0x858/0xf80 [ice]
ice_vc_request_qs_msg+0x1da/0x290 [ice]
ice_vc_process_vf_msg+0xb15/0x1430 [ice]
__ice_clean_ctrlq+0x70d/0x9d0 [ice]
ice_service_task+0x840/0xf20 [ice]
process_one_work+0x690/0xff0
worker_thread+0x4d9/0xd20
kthread+0x322/0x410
ret_from_fork+0x332/0x660
ret_from_fork_asm+0x1a/0x30
Allocated by task 2439:
kasan_save_stack+0x1c/0x40
kasan_save_track+0x10/0x30
__kasan_kmalloc+0x96/0xb0
__kmalloc_noprof+0x1d8/0x580
ice_vsi_cfg_def+0x115c/0x2060 [ice]
ice_vsi_cfg+0xb5/0x3c0 [ice]
ice_vsi_setup+0x180/0x320 [ice]
ice_start_vfs+0x1f3/0x590 [ice]
ice_ena_vfs+0x66d/0x798 [ice]
ice_sriov_configure.cold+0xe4/0x121 [ice]
sriov_numvfs_store+0x279/0x480
kernfs_fop_write_iter+0x331/0x4f0
vfs_write+0x4c4/0xe40
ksys_write+0x10c/0x240
do_syscall_64+0xd9/0x650
entry_SYSCALL_64_after_hwframe+0x76/0x7e
The buggy address belongs to the object at ffff88810affea40
which belongs to the cache kmalloc-32 of size 32
The buggy address is located 0 bytes to the right of
allocated 32-byte region [ffff88810affea40, ffff88810affea60)
Fixes: 288ecf491b ("ice: Accumulate ring statistics over reset")
Reported-by: Michal Schmidt <mschmidt@redhat.com>
Closes: https://redhat.atlassian.net/browse/RHEL-164321
Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Link: https://patch.msgid.link/20260925132636.123300-7-przemyslaw.kitszel@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
ice_vsi_realloc_stat_arrays() resized the ring stats arrays in place
with krealloc_array(), sizing them from vsi->req_txq/req_rxq. That is
not what ice_vsi_set_num_qs() computes later in ice_vsi_cfg_def(), so
after a rebuild the arrays could end up shorter than vsi->alloc_txq /
vsi->alloc_rxq, and ice_vsi_alloc_ring_stats() then walked past their
end.
The VF case shows the divergence. ice_sriov_set_msix_vec_count() writes
vsi->req_txq and then calls ice_vsi_rebuild(), so the old resizer sized
from req_txq, while ice_vsi_get_num_qs() reads vf->num_req_qs ?:
vf->num_vf_qs and ignores req_txq entirely. Once a guest has raised
vf->num_req_qs through VIRTCHNL_OP_REQUEST_QUEUES the two disagree and
the arrays come out shorter than the alloc_txq/alloc_rxq the rebuild
installs. The reset that such a request triggers is a different path,
ice_vf_reconfig_vsi(), which does not use this resizer at all; that one
is handled by the next patch.
Replace it with ice_vsi_resize_stat_arrays(), which allocates a fresh
struct ice_vsi_stats instead, sized with ice_vsi_get_num_qs() and the
queues ice_vsi_decfg() is about to return to the PF pool, which is
exactly what ice_vsi_set_num_qs() will compute once they are back
there, barring a concurrent change of the PF pool; the next patch stops
relying on that. Copy the surviving entry pointers over and install
the new structure, all before ice_vsi_decfg() runs. The entries that
did not fit are freed by ice_vsi_free_unused_stat_arrays(); the old
container itself then goes through __ice_vsi_free_stats() with
@free_entries set to false, since the entries it still points at now
belong to the new structure.
Allocating up front also means a failure no longer leaves a half-updated
ice_vsi_stats behind, with the Tx array already swapped and its surplus
Tx entries already freed, but the Rx allocation failed.
Put the allocate-install-free-surplus sequence in
ice_vsi_install_stat_arrays(), next to ice_vsi_new_stat_arrays(), so
that only the sizing decision is left in the resizer.
Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Link: https://patch.msgid.link/20260925132636.123300-6-przemyslaw.kitszel@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
ice_vsi_set_num_qs() mixed two things: deciding how many queues a VSI
gets, and applying all the side effects of that decision. Split the
decision out into ice_vsi_get_num_qs(), returning both counts at once.
To make that possible, group alloc_txq and alloc_rxq in struct ice_vsi
with struct_group_tagged(), which gives the return type without adding
any new storage. Field order changes slightly, num_txq now follows
alloc_rxq, but nothing depends on it.
ice_vsi_get_num_qs() takes @held_txq and @held_rxq from the start, even
though the only caller so far passes zero for both. They let a caller
ask what the counts would be once the queues the VSI currently owns are
back in the PF pool. A later commit adds the caller that needs this: the
rebuild path has to size its ring stats arrays before ice_vsi_decfg()
releases the queues, yet the arrays must match what ice_vsi_set_num_qs()
computes afterwards.
While reshaping the whole body, drop the kernel-doc line promising a
return value; ice_vsi_set_num_qs() returns void.
No functional change intended.
Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Link: https://patch.msgid.link/20260925132636.123300-5-przemyslaw.kitszel@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Split the allocation of a struct ice_vsi_stats and its two ring stats
arrays out of ice_vsi_alloc_stat_arrays(), which is left with just the
lookup and the store into pf->vsi_stats[].
The sole caller keeps passing the very same queue counts as before,
vsi->alloc_txq and vsi->alloc_rxq. A later commit adds a second caller
in the rebuild path, which cannot use vsi->alloc_* because it has to
size the arrays before the VSI is reconfigured.
Note that the error path no longer clears pf->vsi_stats[vsi->idx]; the
early return above guarantees it is already NULL.
No functional change intended.
Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Link: https://patch.msgid.link/20260925132636.123300-4-przemyslaw.kitszel@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Record the length of each ring stats array in struct ice_vsi_stats, so
that freeing the array entries no longer needs the owning VSI. Keep the
new fields in sync in both places that size the arrays.
With that, the body of ice_vsi_free_stats() becomes independent of the
VSI and can be split out as __ice_vsi_free_stats(). The @free_entries
parameter is always true here; a later commit adds a caller that frees
only the array container, after its entries have been handed over to a
freshly allocated stats structure.
The free path now stops at the recorded length instead of the VSI queue
count, so it follows the real allocation rather than a number that can
disagree with it. Sizing still does not: "ice: rebuild ring stats arrays
instead of reallocating them in place" starts using the lengths to carry
entries over, and only "ice: size ring stats arrays from the final queue
count" makes them authoritative for the allocation path.
Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Link: https://patch.msgid.link/20260925132636.123300-3-przemyslaw.kitszel@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
ice_vsi_alloc_stat_arrays() returns early for ICE_VSI_CHNL, so a channel
VSI never gets an entry in pf->vsi_stats[]. ice_vsi_realloc_stat_arrays()
dereferences that entry unconditionally, and ice_vsi_rebuild() calls it
before anything else, so the NULL is not filtered out anywhere.
The path is live. ice_prepare_for_reset() removes the queue channels only
for resets other than a PFR, so a PFR leaves the channel VSIs in place,
and ice_rebuild() then calls ice_rebuild_channels(), which rebuilds every
ICE_VSI_CHNL VSI it finds. A PF reset with ADQ (mqprio hardware offload)
configured thus dereferences NULL.
That combination is reset recovery on top of an active mqprio offload,
which is why it went unnoticed. It was found while refactoring this code,
not reported by a user.
I'm leaning towards removing our limited (compared to OOT ADQ) support,
but it's outside of this series. Bug could be triggered by:
tc qdisc del dev "$IF" root 2>/dev/null || true
tc qdisc add dev "$IF" root mqprio num_tc 2 \
map 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 \
queues 2@0 2@2 hw 1 mode channel
sleep 3
ethtool --reset "$IF" irq dma filter offload
Workqueue: ice ice_service_task [ice]
RIP: 0010:ice_vsi_rebuild+0x289/0x380 [ice]
ice_rebuild_channels+0xd6/0x320 [ice]
ice_rebuild+0x4f6/0x540 [ice]
ice_do_reset+0x9f/0x1a0 [ice]
ice_service_task+0x4a/0x460 [ice]
Fixes: 5995ef88e3 ("ice: realloc VSI stats arrays")
Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Link: https://patch.msgid.link/20260925132636.123300-2-przemyslaw.kitszel@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
When tcp_collapse() rebuilds skbs under memory pressure, the copy
process doesn't include the right tstamp and hwtstamp from the
old skb. And memcpy(nskb->cb, skb->cb, ...) copies has_rxtstamp,
but nskb->tstamp and hwtstamps are left at zero, so
tcp_recv_timestamp() ends up emitting no cmsg at all.
In net timestamping case, if such an skb happens to be the last
one consumed in a recvmsg() call, the application receives no RX
timestamp for that call.
Fix this by copying both tstamp and hwtstamp of the last skb to
the new skb, matching tcp_try_coalesce()/tcp_add_backlog().
Note that the has_rxtstamp flag can still be inherited through
the cb memcpy from an skb that contributes no bytes (fully covered
skb left in the ofo tree by the tcp_ooo_try_coalesce() ->
coalesce_done path), so set TCP_SKB_CB(nskb)->has_rxtstamp to false
which makes the new block the only place setting it.
Signed-off-by: Jason Xing <kerneljasonxing@gmail.com>
Reviewed-by: Eric Dumazet <edumazet@kernel.org>
Link: https://patch.msgid.link/20260924152529.5689-1-kerneljasonxing@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Matthieu Baerts says:
====================
mptcp: misc improvements for v7.4
Here are some unrelated improvements for MPTCP:
- Patch 1: reduce struct mptcp_subflow_context size: no need to store
the truncated HMAC for the whole connection.
- Patches 2-3: shrink struct mptcp_options_received used to parse
incoming MPTCP options, from 136 to 72 bytes on x86_64.
====================
Link: https://patch.msgid.link/20260926-net-next-mptcp-misc-feat-7-4-v1-0-67af4ab37406@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
struct mptcp_options_received is allocated on the stack while parsing
incoming MPTCP options. Several suboptions are mutually exclusive, as
enforced by mptcp_parse_option(), so their payloads can overlap.
Group fields by suboption and place the mutually exclusive payloads in
an anonymous union. Keep DSS and rm_list outside the union: they can
be combined with other suboptions. Move join_id into the MP_JOIN
group, and overlap token, thmac and hmac inside that group.
Further shrinking would require changing the parser so currently
coexisting fields (DSS mapping vs ACK, rm_list, status flags) can
overlap. That adds complexity for little gain, since the outer union is
already dominated by the MP_JOIN / ADD_ADDR members.
This reduces the structure size from 136 to 72 bytes on x86_64.
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/625
Signed-off-by: Quanye Yang <quanyeyang@proton.me>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260926-net-next-mptcp-misc-feat-7-4-v1-3-67af4ab37406@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
