The V2 SR-IOV design uses a dedicated admin channel (WQ/RQ/CQ
resources plus an MSI-X interrupt) for PF-VF mailbox communication rather
than firmware-proxied devcmds.
Introduce enic_admin_channel_open() and enic_admin_channel_close().
Open allocates and initialises the admin WQ, RQ, and two CQs (one per
direction), then issues CMD_QP_TYPE_SET to tell firmware the queues are
admin-type. Close reverses the sequence.
enic_admin_wq_buf_clean() unmaps and frees any WQ buffers still held
at close time, fixing a DMA mapping leak when a send times out.
Add CMD_QP_TYPE_SET (97), QP_TYPE_ADMIN/DATA, and QP_ENABLE/QP_DISABLE
defines to vnic_devcmd.h. Add VNIC_CQ_* named constants to vnic_cq.h
so CQ initialisation parameters are self-documenting from their first
introduction.
Signed-off-by: Satish Kharat <satishkh@cisco.com>
Link: https://patch.msgid.link/20260812-enic-sriov-v2-admin-channel-v2-v13-2-b3809e448aba@cisco.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
During PF probe, query the firmware get-supported-feature interface
to verify that the running firmware supports V2 SR-IOV. Firmware
version 5.3(4.72) and later report VIC_FEATURE_SRIOV via
CMD_GET_SUPP_FEATURE_VER. If the firmware does not support the
feature, set vf_type to ENIC_VF_TYPE_NONE and log a warning so the
admin knows a firmware upgrade is needed.
The V2 admin-channel and MBOX bring-up added later in this series is
gated on ENIC_VF_TYPE_V2, so this downgrade keeps those paths from
running on firmware that does not support V2 SR-IOV.
VIC_FEATURE_SRIOV is assigned the explicit value 4 to match the
firmware ABI. Slot 3 (firmware's VIC_FEATURE_PTP) is reserved with
a comment rather than a placeholder enum entry, since PTP is not
used by the upstream driver.
Suggested-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Satish Kharat <satishkh@cisco.com>
Reviewed-by: Breno Leitao <leitao@debian.org>
Link: https://patch.msgid.link/20260812-enic-sriov-v2-admin-channel-v2-v13-1-b3809e448aba@cisco.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Matthieu Baerts says:
====================
mptcp: misc. features for v7.3
This series contains a few independent new features, and small fixes for
net-next:
- Patch 1: Add WARN_ON_ONCE guards around extra_subflows to catch issues
with this counter, similar to what is done with other PM counters.
- Patches 2-3: Follow-up patches to remove data_ack field from struct
mptcp_ext -- now unused after recent fixes -- and makes a userspace PM
helper static.
- Patch 4: Honour tcp_rto_{min_us,max_ms} sysctls for MPTCP-level
retransmit timers like with DATA_FIN's and fallback timeout.
- Patches 5-6: Add per-event MIB counters for MPTCP_RST_EMPTCP resets to
help to spot such situations in production.
- Patches 7-9: Small pcap-related improvements in the selftests.
- Patch 10: Fix compiler warning in the selftests.
- Patch 11: Avoid a buffer overflow when misusing the mptcp_diag tool
from the selftests.
====================
Link: https://patch.msgid.link/20260812-net-next-mptcp-misc-feat-7-3-v1-0-1905a818f6cb@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
get_subflow_info() parses the subflow address string with:
char saddr[64], daddr[64];
ret = sscanf(subflow_addrs, "%[^:]:%d %[^:]:%d",
saddr, &sport, daddr, &dport);
The subflow_addrs buffer holds up to 1024 bytes and is taken directly
from the command line ("-c" argument). The "%[^:]" conversions have no
maximum field width, so if the address substring before the ':' exceeds
63 bytes, sscanf() writes past the end of the 64-byte saddr/daddr stack
buffers. This overflows the stack, corrupting adjacent stack data such
as the saved return address, and can crash the tool or lead to
out-of-bounds writes controlled by user-supplied input.
Bound both string conversions to the destination buffer size by adding
an explicit maximum field width of 63 (leaving room for the terminating
NUL), so at most 63 bytes are written into each 64-byte buffer:
ret = sscanf(subflow_addrs, "%63[^:]:%d %63[^:]:%d",
saddr, &sport, daddr, &dport);
The subflow address can be passed in argument, so fixing this is helpful
when the tool is manually used.
Reviewed-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Jiangshan Yi <yijiangshan@kylinos.cn>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260812-net-next-mptcp-misc-feat-7-3-v1-11-1905a818f6cb@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In mptcp_connect.c, strchr() returns a pointer to a character within
the input string, which is declared as const char *. Assigning this
return value to a non-const char * discards the const qualifier,
triggering compiler warnings:
make: Entering directory 'tools/testing/selftests/net/mptcp'
CC mptcp_connect
mptcp_connect.c: In function 'parse_cmsg_types':
mptcp_connect.c:1267:22: warning: initialization discards 'const'
qualifier from pointer target type [-Wdiscarded-qualifiers]
1267 | char *next = strchr(type, ',');
| ^~~~~~
mptcp_connect.c: In function 'parse_setsock_options':
mptcp_connect.c:1295:22: warning: initialization discards 'const'
qualifier from pointer target type [-Wdiscarded-qualifiers]
1295 | char *next = strchr(name, ',');
| ^~~~~~
make: Leaving directory 'tools/testing/selftests/net/mptcp'
Fix these warnings by declaring the 'next' variable as const char *,
as it is only used for read-only parsing.
Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260812-net-next-mptcp-misc-feat-7-3-v1-10-1905a818f6cb@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Limit the size of each captured packet to 108B (IPv4 only) or 128B (a
mix of v4 and v6): this should drop most of the payload that is
generally not needed when debugging an issue.
8 bytes are left in this payload, to be able to inspect the beginning,
just in case.
Please also note that generally, this payload is usually mostly filled
with 0, except at the end. This reduces the .pcap sizes, and reduce IO
usage, which helps debugging issues.
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260812-net-next-mptcp-misc-feat-7-3-v1-9-1905a818f6cb@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add named env-var expectations for each per-event MPTCP_RST_EMPTCP
counter, matching the pattern used by the existing JOIN/RST checks.
Each defaults to 0 and is checked silently on success; a mismatch prints
a check line and fails the test. Counters absent from the running
kernel are skipped silently so older kernels do not false-fail.
The JOIN-related counters (MPJoinSynAckNoMPJoin, MPJoinAckNoMPJoin,
MPJoinAckNoCtx, MPJoinNotEstablished, MPJoinNoIdFound) are checked in
chk_join_nr() on fixed namespaces; the two remaining reset counters
(MD5SigReset, DssReset) stay in chk_rst_nr().
Add a test at the end of signal_address_tests that triggers
MPJoinSynAckNoMPJoin: ns1 signals an address that is already bound on
the client (ns2), where a TCP-only mptcp_connect listener is started.
The client's MP_JOIN routes locally to the TCP listener, which responds
with a plain SYN/ACK without the MP_JOIN option, and the new counter
increments on the client side.
Other per-event counters (MD5SigReset, MPJoinAckNoMPJoin, MPJoinAckNoCtx,
DssReset, MPJoinNotEstablished, MPJoinNoIdFound) are not currently
reachable from mptcp_join.sh; the env-var hooks are in place for future
tests to set expectations explicitly.
Signed-off-by: Shardul Bankar <shardul.b@mpiricsoftware.com>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260812-net-next-mptcp-misc-feat-7-3-v1-6-1905a818f6cb@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
MPTCP_RST_EMPTCP (reset reason 1) is used as a catch-all for several
distinct error conditions across subflow setup, authentication, and
data-path validation. The existing MPRstTx/MPRstRx counters only
track aggregate reset volume, making it difficult to diagnose which
code path is triggering subflow resets in production.
Add per-event MIB counters covering each MPTCP_RST_EMPTCP use site
that is not already covered by an existing counter, named after the
underlying event or condition rather than the reset action:
MD5SigReset MD5SIG enabled on listener (incompatible)
MPJoinSynAckNoMPJoin SYN/ACK missing MP_JOIN option
MPJoinAckNoMPJoin server-side ACK missing MP_JOIN option
(fallback path, MPJoin required)
MPJoinAckNoCtx server-side ACK with no subflow context
MPJoinNoIdFound MP_JOIN with a valid token but no PM local ID
DssReset data mapping invalid (also fires on
MAPPING_NODSS / EMIDDLEBOX path)
MPJoinNotEstablished JOIN attempted on a not-fully-established msk
MPJoinNoIdFound covers the second half of the no-msk MP_JOIN reset:
the existing MPJoinNoTokenFound (MPTCP_MIB_JOINNOTOKEN) only counts the
missing-token case in subflow_token_join_request(), while a JOIN that
carries a valid token but for which the path manager returns no local
id reaches the same MPTCP_RST_EMPTCP in subflow_check_req() uncounted.
The aggregate MPRstTx/MPRstRx counters are unchanged.
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/511
Signed-off-by: Shardul Bankar <shardul.b@mpiricsoftware.com>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260812-net-next-mptcp-misc-feat-7-3-v1-5-1905a818f6cb@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The MPTCP-level retransmit timers (DATA_FIN retransmissions and the
fallback timeout) used the hard-coded TCP_RTO_MIN / TCP_RTO_MAX
constants, ignoring the tcp_rto_min_us and tcp_rto_max_ms sysctls.
Make them follow the sysctls instead: seed icsk_rto_min / icsk_rto_max
on the MPTCP socket from the per-netns sysctls in __mptcp_init_sock()
-- the msk does not go through tcp_init_sock(), so these fields would
otherwise stay zero -- and read them directly where the constants were
used:
- mptcp_set_datafin_timeout(): both the backoff cap computation and
the resulting timer_ival. The two sysctls are validated
independently, so rto_min > rto_max is a valid configuration; keep
a max_t() guard so ilog2() is never called with 0.
- __mptcp_set_timeout(): the fallback when no subflow timeout is
available.
The icsk fields are read directly instead of using the
tcp_rto_min()/tcp_rto_max() helpers: the MPTCP socket does not perform
routing lookups in these paths, so the rto_min route metric checked by
tcp_rto_min() can never apply here. The TCP_RTO_MIN_US /
TCP_RTO_MAX_MS socket options are not supported by MPTCP setsockopt()
either; this can be revisited if they get supported on MPTCP sockets.
The remaining uses of TCP_RTO_MAX in net/mptcp/ctrl.c (default
add_addr_timeout) and net/mptcp/subflow.c (MP_FAIL timeout) are
intentionally left unchanged: they use the constant as a default
duration, not as an RTO bound on a retransmit timer.
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/618
Signed-off-by: Kalpan Jani <kalpan.jani@mpiricsoftware.com>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260812-net-next-mptcp-misc-feat-7-3-v1-4-1905a818f6cb@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
EMAC has never supported changing ring sizes: RX is hardcoded to 9 and
TX is the tiniest ring buffer you can imagine.
Make sure the operation fails early rather than silently succeed and
storing values in bp->configured_{rx,tx}_ring_size that are never read
in the EMAC case.
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Link: https://patch.msgid.link/20260812-macb-context-v9-7-7ddbf5f715e0@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The tieoff descriptor is a RX DMA descriptor ring of size one. It gets
configured onto queues for Wake-on-LAN during system-wide suspend when
hardware does not support disabling individual queues
(MACB_CAPS_QUEUE_DISABLE).
MACB/GEM driver allocates it alongside the main RX ring
inside macb_alloc() at open. Free is done by macb_free() at close.
Change to allocate once at probe and free on probe failure or device
removal. This makes the tieoff descriptor lifetime much longer,
avoiding repeating coherent buffer allocation on each open/close cycle.
Main benefit: we dissociate its lifetime from the main ring's lifetime.
That way there is less work to be doing on resources (re)alloc. This
currently happens on close/open, but will soon also happen on context
swap operations (set_ringparam, change_mtu, set_channels, etc).
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Link: https://patch.msgid.link/20260812-macb-context-v9-6-7ddbf5f715e0@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Martino Dell says:
====================
net: sfp: quirk support for XGS-PON ONT sticks with unclean EEPROMs
Some clone XGS-PON ONT sticks return EEPROM reads where the vendor PN
field contains non-printable garbage past the legitimate string instead
of the SFF-8472 mandated space padding. sfp_strlen() then can't trim
the field, the exact-length check in sfp_match() rejects the quirk
entry before the string comparison runs, and the quirk silently never
applies - so the kernel honors the module's spurious TX_FAULT and
eventually disables it.
Patch 1 adds an opt-in part-prefix-matching flag to the quirk table so
such modules can still be matched; the vendor name is always matched
exactly and existing entries behave as before. Patch 2 adds two ONT
stick entries wired to the existing potron fixup: the "OEM"
XGSPONST2001, which needs the prefix matching (it returns trailing
garbage in the PN field on cold power-up reads), and the Fiberstore
XGS-SFP-ONT-MACI, whose PN field is fully occupied by the truncated
product name and matches exactly.
Both quirks are in production use on a Bananapi BPI-R4 (MT7988A)
router on an XGS-PON uplink, backported onto 6.12.
====================
Link: https://patch.msgid.link/20260812154708.2201266-1-tillo@tillo.ch
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Cheap XGS-PON ONT sticks identifying as vendor "OEM", PN "XGSPONST2001"
have broken TX_FAULT and LOS indicators (driven by the ONU serial
passthrough wires) and need a longer T_START_UP than the SFF-8472
default. The Fiberstore XGS-SFP-ONT-MACI MAC-mode ONT stick has the
same ONT-class TX_FAULT/LOS wiring and startup behaviour. Apply the
existing sfp_fixup_potron handler to both, which masks both signals
and bumps T_START_UP to T_START_UP_BAD_GPON.
The XGSPONST2001 returns the 12 legitimate PN characters followed by
non-printable garbage on cold power-up reads (the same module reads
back clean and space-padded after a warm reseat), which defeats
exact-length matching precisely on the boot where the quirk must
apply: the kernel honors the spurious TX_FAULT and the SFP state
machine eventually disables the module. Match its part as a prefix
using SFP_QUIRK_F_PREFIX.
The XGS-SFP-ONT-MACI PN is the product name (XGS-SFP-ONT-MAC-I)
truncated at the 16-byte field width, so the field is fully occupied
by legitimate characters and a plain exact-match SFP_QUIRK_F entry is
correct.
Signed-off-by: Martino Dell'Ambrogio <tillo@tillo.ch>
Link: https://patch.msgid.link/20260812154708.2201266-3-tillo@tillo.ch
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Some clone SFP modules return EEPROM reads where the vendor PN field
contains non-printable garbage past the trailing legitimate characters
instead of the SFF-8472 mandated space padding. The current sfp_match()
requires an exact full-field length match: sfp_strlen() returns 16 (no
trailing spaces or NULs to strip), but strlen() of the quirk string is
shorter, so the length comparison rejects the entry before strncmp() is
even called and the quirk silently never applies.
Add a part_prefix_match flag to struct sfp_quirk and a
SFP_QUIRK_F_PREFIX macro. When set, sfp_match() compares only strlen()
leading bytes of the quirk part string, ignoring trailing field bytes.
The vendor name comparison always stays exact. Existing exact-match
quirks are unaffected (part_prefix_match defaults to false via zero-init
in the existing SFP_QUIRK macros).
This patch only adds the mechanism; the first user is added by the
following patch.
Signed-off-by: Martino Dell'Ambrogio <tillo@tillo.ch>
Link: https://patch.msgid.link/20260812154708.2201266-2-tillo@tillo.ch
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
pktgen_if_write() can update cflows while the packet generator thread is
inside mod_cur_headers(). The latter first tests cflows, but f_pick() then
reloads it when selecting a random flow.
This allows the following interleaving:
CPU 0 (kpktgend) CPU 1 (proc write)
if (pkt_dev->cflows) // 10
pkt_dev->cflows = 0
get_random_u32_below(pkt_dev->cflows)
get_random_u32_below(0) returns a full-width random value. Using that
value as an index into the fixed-size flows array causes an out-of-bounds
access. The kernel reported:
BUG: unable to handle page fault for address: ffffc8fe2d2674bc
#PF: supervisor read access in kernel mode
Oops: Oops: 0000 [#1] SMP KASAN NOPTI
CPU: 0 UID: 0 PID: 65 Comm: kpktgend_0
RIP: 0010:mod_cur_headers+0x16f8/0x2840
Call Trace:
<TASK>
pktgen_thread_worker+0x305a/0x6bc0
kthread+0x2c6/0x3b0
ret_from_fork+0x36e/0x5a0
ret_from_fork_asm+0x1a/0x30
</TASK>
Read cflows once at the start of mod_cur_headers(), pass the snapshot to
f_pick(), and use it for later flow-state decisions in the same packet.
Publish proc updates with WRITE_ONCE(). Flow selection then always uses a
nonzero count bounded by MAX_CFLOWS, while a concurrent update takes
effect on a later packet.
Cc: stable+noautosel@kernel.org # needs real net-admin (non-ns)
Signed-off-by: Chengfeng Ye <nicoyip.dev@gmail.com>
Signed-off-by: Qi Zhang <marsy12010123@gmail.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
airoha_npu_load_firmware() maps a missing firmware file to -EPROBE_DEFER
so that the NPU can be brought up once the rootfs carrying /lib/firmware
has been mounted. That mapping holds only as long as request_firmware()
reports -ENOENT.
It does not when the sysfs fallback is in play. With
CONFIG_FW_LOADER_USER_HELPER_FALLBACK set, or with the fallback armed at
runtime through /proc/sys/kernel/firmware_config/force_sysfs_fallback,
request_firmware() hands the request to a userspace helper, waits out the
full loading_timeout and returns -ETIMEDOUT. The -ENOENT test no longer
matches, dev_err_probe() turns the result into a hard failure, and the
NPU is left unbound after stalling the boot for 60 seconds:
airoha-npu 1e900000.npu: Direct firmware load for airoha/en7581_npu_rv32.bin failed with error -2
airoha-npu 1e900000.npu: Falling back to sysfs fallback for: airoha/en7581_npu_rv32.bin
airoha-npu 1e900000.npu: error -ETIMEDOUT: failed to run npu firmware
airoha-npu 1e900000.npu: probe with driver airoha-npu failed with error -110
Clearing FW_LOADER_USER_HELPER in the configuration is not a dependable
guard against this, because unrelated drivers select it. On the affected
build the symbol was turned back on by LEDS_LP55XX_COMMON, even though
the platform had explicitly disabled it.
Use request_firmware_direct() instead. It sets FW_OPT_NOFALLBACK_SYSFS,
so a missing file is reported as -ENOENT whatever the firmware loader is
configured to do, and the deferred probe path works as intended.
Two consequences are worth stating plainly.
The helper is not merely bypassed for the boot-before-rootfs case.
fw_run_sysfs_fallback() returns early on FW_OPT_NOFALLBACK_SYSFS, so this
driver's firmware requests can no longer be served by a usermode helper
at all, including on a system where that is the only delivery route;
having no second firmware source, the driver would defer forever there.
That is a deliberate trade-off: the -ENOENT to -EPROBE_DEFER mapping was
written to wait for a filesystem, and the sysfs helper interface has had
no in-tree consumer since udev dropped firmware loading.
request_firmware_direct() also sets FW_OPT_NO_WARN, which drops the only
message naming the file that failed to load. Report it from the driver
instead, so the name lands in the deferred probe reason and shows up in
the "deferred probe pending" line emitted at
driver_deferred_probe_timeout. The generic report in airoha_npu_probe()
goes away with it, since it would otherwise overwrite that reason with a
message naming nothing; of the paths it covered, devm_ioremap_resource()
reports itself and the malformed firmware-name property now does too.
Measured on a Nokia XG-040G-MD with FW_LOADER_USER_HELPER=y and
FW_LOADER_USER_HELPER_FALLBACK=y forced on, two images from the same
tree differing only by this patch:
without: fallback at 2.477s -> -ETIMEDOUT at 64.555s -> probe failed
with -110, preinit at 69.6s, NPU unbound
with: no fallback, NPU fw version 1456.62 at 3.665s, preinit at
7.6s
Cc: stable+noautosel@kernel.org # never worked
Signed-off-by: Vitaliy Sochnev <sochnev.v.74@gmail.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In jumbo_frm() (implemented in both "chain_mode.c" and "ring_mode.c"),
there are places where a DMA descriptor is converted to little-endian
byte order in assignment. The DMA descriptor could be a 64-bit value,
which makes the 32-bit byte swapping operation seem a little sketchy.
Explicitly extract the low-order 32 bits of the dma_addr_t value being
converted into a u32 so it's crystal clear that we're doing the right
thing.
Suggested-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Signed-off-by: Alex Elder <elder@riscstar.com>
Link: https://patch.msgid.link/20260812163832.271742-3-elder@riscstar.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
No functional changes.
In code paths that use a psp_dev reference that wasn't obtained from
the psp_devs xarray, e.g. not via psp_device_get_and_lock(), there is
no guarantee that the psp_dev has not been unregistered. The check
here is correct, but it doesn't match other code paths that use
psp_dev_is_registered().
Commit b89769f936 ("net: psp: check for device unregister when
creating assoc") is an example of a fix that adds a check for this
after locking a psp_dev. if (psp_dev_is_registered(psd)) vs if
(psd->ops) makes it clear what we are really checking for.
Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com>
Link: https://patch.msgid.link/20260814-psp-dev-is-reg-v1-1-5029e1f1eb01@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The ipv6_flowlabel_mgr used to be a component of a broader overall
flow label test, defined in the ipv6_flowlabel.sh file. This wrapper
script called tests defined on ipv6_flowlabel.c and
ipv6_flowlabel_mgr.c files, using predefined parameters and enforcing
the in_netns.sh helper to set network namespaces for each test env.
However, the ipv6_flowlabel_mgr.c was drastically changed recently.
These modifications led to the mgr tests becoming a self contained and
independent test suite, enforcing netns creation by itself and
not relying on the ipv6_flowlabel.sh wrapper for proper test execution
anymore. Therefore, remove the mgr tests from the wrapper and update
the Makefile to handle it as a standalone test program instead.
Signed-off-by: Marcelo Mendes Spessoto Junior <marcelomspessoto@gmail.com>
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Link: https://patch.msgid.link/20260813030708.37609-1-marcelomspessoto@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jakub Kicinski says:
====================
eth: bnxt: preserve IRQ affinity across IRQ reallocation
bnxt currently discards the IRQ affinity when changing ring count:
# ethtool -l ens9np0
[...] Combined: 8 [...]
# ynl --family netdev --dump napi-get --json '{"ifindex": 2}'
[...]
{'defer-hard-irqs': 0,
'gro-flush-timeout': 0,
'id': 70,
'ifindex': 2,
'irq': 170, << IRQ 170 is for NAPI 1 (second to last)
'irq-suspend-timeout': 0,
'threaded': 'disabled'},
{'defer-hard-irqs': 0,
'gro-flush-timeout': 0,
'id': 69,
'ifindex': 2,
'irq': 169,
'irq-suspend-timeout': 0,
'threaded': 'disabled'}]
# cat /proc/irq/170/smp_affinity_list
1 <<< system config script set CPU 1 for this IRQ
# ethtool -L ens9np0 combined 1
# ethtool -L ens9np0 combined 8
# cat /proc/irq/170/smp_affinity_list
0-31 <<< system has 32 CPUs
After this series:
# cat /proc/irq/170/smp_affinity_list
1
# ethtool -L ens9np0 combined 1
# ethtool -L ens9np0 combined 8
# cat /proc/irq/170/smp_affinity_list
1
We recently added the ability to networking core to track the affinity.
bnxt doesn't use it because it needs TPH programming as well.
Let's align its local behavior.
The loss of IRQ config is a real production problem, but it also breaks
some of the NIPA tests.
====================
Link: https://patch.msgid.link/20260813193248.2578626-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reconfiguring the rings frees the MSI-X vectors and allocates them
again. The IRQ descriptors go away with them, so the affinity user
space set is silently replaced by the driver's default NUMA spread.
This is painful to deal with for user space as seemingly arbitrary
NIC configuration changes lead to loss of configuration.
In NIPA (netdev CI) this results in the toeplitz test reporting:
Exception| net.lib.py.ksft.KsftFailEx: IRQ170 is not mapped to a single core: 0-31
if the test run after another test which reconfigured the device.
We configure the IRQ mapping at boot, but if the driver is not
preserving the config - it gets lost.
Record the affinity in the notifier and apply it when the IRQs are
requested again. The notifier has to be registered unconditionally
now, so far it was only installed when TPH was enabled. Drivers
which let the core manage the affinity (idpf, ice, iavf via
netif_set_affinity_auto()) work exactly like this,
napi_restore_config() reapplies napi_config.affinity_mask on every
napi_enable().
Note that the affinity is supposed to follow the NAPI / queue,
same as the napi_config behavior in drivers mentioned above.
If the user changes the affinity when the device is down -
we will override it on up. That's expected, the IRQs are not
associated with queues when device is down (no name, no entry
in /proc/interrupts, no entry in netdev netlink).
map_idx is ulp_msix + i, so the slot shifts whenever RoCE takes
or releases vectors and the mask would end up on a different ring.
Key using the completion ring id, which maps to the NAPI instance.
Note2: this restores the side effect fcf42409c6 ("bnxt_en: use
irq_update_affinity_hint()") removed, but not the problem it was
fixing. The complaint there was that reopening the device resets
the affinity and can move an IRQ onto a CPU irqbalance was told
to stay away from. We now replay what user space or irqbalance
last asked for, the driver's own placement is only used for
a ring nobody has configured.
Note3: the combined irq_set_affinity_and_hint() looks like
it may hide the failure from __irq_set_affinity(), but let's
assume the IRQ maintainers know what their doing - either
this can't happen or is intentional.
Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
Link: https://patch.msgid.link/20260813193248.2578626-3-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
rtl8168_setup_ldev() and rtl8125_setup_led_ldev() build the LED device
name in a stack buffer and assign it to led_cdev->name.
The LED class device registration path reads led_cdev->name after it has
been assigned, and struct led_classdev stores the name as part of the LED
class device state. Do not keep a pointer to a setup function's stack
buffer there.
Store the name in struct r8169_led_classdev instead, so it remains valid
for the lifetime of the LED class device.
Signed-off-by: Zhixing Chen <running910@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260813100711.14724-1-running910@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Eric Dumazet says:
====================
net: prevent lockless data races in net_device TC structures
This patch series resolves lockless data races between fast-path packet
processing / qdisc schedulers (e.g. taprio advance_sched(), XPS queue
lookups, skb_tx_hash()) and control-path updates modifying traffic class
configurations on a net_device.
syzbot / KCSAN reported a data-race between advance_sched() reading
dev->num_tc in netdev_get_num_tc() and control-path updates writing
dev->num_tc in netdev_set_num_tc():
==================================================================
BUG: KCSAN: data-race in advance_sched / netdev_set_num_tc
write to 0xffff88811ac5c036 of 2 bytes by task 4434 on cpu 0:
netdev_set_num_tc+0x... net/core/dev.c:3158
...
tc_modify_qdisc+0x102a/0x1550 net/sched/sch_api.c:1844
rtnetlink_rcv_msg+0x6a7/0x720 net/core/rtnetlink.c:7085
read to 0xffff88811ac5c036 of 2 bytes by interrupt on cpu 1:
netdev_get_num_tc include/linux/netdevice.h:2684 [inline]
taprio_set_budgets net/sched/sch_taprio.c:667 [inline]
advance_sched+0x58f/0x730 net/sched/sch_taprio.c:984
__run_hrtimer kernel/time/hrtimer.c:2032 [inline]
__hrtimer_run_queues+0x1f8/0x510 kernel/time/hrtimer.c:2096
value changed: 0x0000 -> 0x0001
==================================================================
Further inspection of the TC metadata structures on struct net_device
revealed three separate issues under concurrent lockless access:
1. struct netdev_tc_txq holds adjacent 16-bit offset and count fields
that are written separately in netdev_set_tc_queue() (and cleared
via memset() during reset), allowing lockless readers in fast-path
helpers and drivers to observe torn/inconsistent states. This is fixed
in Patch 1 by wrapping count and offset in a union with a u32
combined field manipulated atomically via READ_ONCE()/WRITE_ONCE().
2. dev->num_tc is read locklessly in fast-path lookups and timer
interrupts without READ_ONCE() annotations, while control paths modify
it using plain writes. Patch 2 adds READ_ONCE()/WRITE_ONCE()
annotations across core networking code and drivers.
3. dev->prio_tc_map is similarly read locklessly in fast-path helpers
such as skb_tx_hash() while control paths update entries or clear the
map via memset(). Patch 3 adds READ_ONCE()/WRITE_ONCE() annotations
to netdev_get_prio_tc_map() and netdev_set_prio_tc_map() and replaces
memset() with explicit atomic store loops.
Reported-by: syzbot+a181d44496a497911353@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/netdev/6a7c3457.d5f0ebe7.22d851.000a.GAE@google.com/T/#u
====================
Link: https://patch.msgid.link/20260812085440.3917924-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Concurrent fast-path readers access dev->prio_tc_map (e.g. via
skb_tx_hash(), netdev_get_prio_tc_map(), and qdiscs) while writers
update entries in dev->prio_tc_map or reset/clear the map via
netdev_reset_tc() and netdev_unbind_sb_channel().
Furthermore, memset() in netdev_reset_tc() and
netdev_unbind_sb_channel() provides no guarantee of performing
atomic word/byte stores.
Add READ_ONCE() and WRITE_ONCE() annotations to netdev_get_prio_tc_map()
and netdev_set_prio_tc_map(), replace memset() in dev.c with explicit
WRITE_ONCE() loops, and update direct array accesses in qdiscs to use
netdev_get_prio_tc_map().
Signed-off-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260812085440.3917924-4-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Several fast-path and control-path lockless readers access dev->num_tc
(e.g., skb_tx_hash(), netdev_txq_to_tc(), netdev_get_num_tc(), and
qdisc/driver lookups) while concurrent writers update dev->num_tc
during TC setup, device reset, or channel configuration.
Add READ_ONCE() and WRITE_ONCE() annotations to prevent compiler
reordering and load/store tearing when accessing dev->num_tc.
Update inline helpers in netdevice.h (netdev_get_num_tc(),
netdev_set_prio_tc_map(), and netdev_get_sb_channel()) as well as
writers and lockless readers in core networking code and drivers.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260812085440.3917924-3-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
netdev_set_tc_queue() (and related helpers/drivers such as
netdev_bind_sb_channel_queue(), netdev_reset_tc(), and
netdev_unbind_sb_channel()) perform separate 16-bit writes to
dev->tc_to_txq[tc].count and dev->tc_to_txq[tc].offset.
Furthermore, memset() in netdev_reset_tc() and
netdev_unbind_sb_channel() provides no guarantee of performing
full 32-bit word stores.
Concurrent lockless readers (e.g. skb_tx_hash(), netdev_txq_to_tc(),
ixgbe_select_queue(), taprio, mqprio, FPE drivers) can observe torn
values where offset and count belong to inconsistent configurations.
Redefine struct netdev_tc_txq to embed count and offset inside a union
with a u32 combined field, allowing atomic manipulation via
READ_ONCE() and WRITE_ONCE().
Update all lockless readers and writers across the kernel to use
READ_ONCE() and WRITE_ONCE() on the combined field.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260812085440.3917924-2-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
For IPv4 ERSPAN:
In erspan_xmit(), the driver clears IP_TUNNEL_SEQ_BIT (for version 0)
and IP_TUNNEL_KEY_BIT directly in the shared tunnel->parms.o_flags
structure. Since transmit paths can run locklessly and concurrently,
this leads to a data race.
Furthermore, modifying tunnel->parms.o_flags permanently alters the
tunnel configuration. To work around this, erspan_fill_info() (which
reports config to userspace) was setting IP_TUNNEL_KEY_BIT back. If
erspan_fill_info (running under RTNL) and erspan_xmit (running locklessly)
race, erspan_xmit might see IP_TUNNEL_KEY_BIT set when it shouldn't,
leading to GRE header corruption (injecting a key field into the ERSPAN
GRE header).
Fix this by:
1) Passing flags as an argument to __gre_xmit().
2) Using local stack flags in ipgre_xmit(), gre_tap_xmit(), and erspan_xmit()
to prevent TOCTOU data races with concurrent configuration updates,
and passing them to __gre_xmit().
3) Removing the racy modification of t->parms.o_flags in erspan_fill_info().
4) Forcing IP_TUNNEL_KEY_BIT in the reported flags for ERSPAN locally
in ipgre_fill_info().
For IPv6 ERSPAN:
ip6erspan_tunnel_xmit() was locklessly clearing IP_TUNNEL_KEY_BIT in
t->parms.o_flags even though it does not use these flags for building
the GRE header (it uses local flags). This permanently corrupts the
configuration and races with ip6gre_fill_info() which reads it.
Remove the redundant and racy modification.
This should remove false sharing in a fast path.
Add const qualifiers in ipgre_fill_info(), erspan_fill_info()
and ip6gre_fill_info() to clarify that these methods are not
supposed to write any live parameters.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260812142257.21283-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Newer FW reports the SD group size directly in the NIC vport context
via the sd_group_size field, gated by the sd_group_size capability.
Switch sd_init() to source the group size from there and fall back to
the MPIR-based host_buses query only when the cap is absent.
sd_group_size might return 1 in some FW configuration. Add explicit
check to disable SD creation in this case.
While here, rename host_buses to group_size throughout sd.c to follow
the new name on capable FW.
Signed-off-by: Shay Drory <shayd@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260810093037.3138197-1-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Pablo Neira Ayuso says:
====================
Netfilter updates for net
This includes an enhancement to detect ct memleaks easier via
DEBUG_NET and flowtable preparation patches for IPv4 over IPV6
and vice-versa. This also includes a fix for the nft_ct custom
expectation support.
1) Add DEBUG_NET_WARN_ON_ONCE to nf_ct_set() to spot ct memleaks.
2) Pass struct net_device_path_ctx to dev_fill_forward_path() to
make it easier to pass more parameters to this function.
From Lorenzo Bianconi.
3) Add ether_type field to net_device_path context structucture.
4) Rename tun.l3_proto field to tun.inner_proto.
5) Rename ctx.tun.proto to ctx.tun.inner_proto.
6) Store ether_type in flowtable context.
7) Move IPv4 and IPv6 xmit path to a helper function.
8) Move encapsulation header parser out of the flowtable lookup
function.
9) Rework nft_ct custom expectation support to address a possible
reallocation of ct extension area while expectation list also
contains expectations. Move datapath to a ct helper to fix it.
10) Ensure timeout is always lowered for the non-closing RST case
in the TCP connection tracking.
11) Bail out when inserting already dead expectation, this should
not ever happen, hence report it via DEBUG_NET.
12) Comestic updates for improving the conntrack selftest dump and
flush userspace program, from Qingshuang Fu.
* tag 'nf-next-26-08-10' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next:
selftests: netfilter: conntrack_dump_flush: remove unused variables and fix typo
netfilter: nf_conntrack_expect: bail out on insert dead expectations
netfilter: conntrack: always lower timeout for non-closing RST packets
netfilter: nft_ct: move custom expectation support to helper
netfilter: flowtable: detach layer 2 encapsulation parser from lookup
netfilter: flowtable: move ipv4 and ipv6 xmit path to function
netfilter: flowtable: store ethertype in flowtable context
netfilter: flowtable: rename ctx.tun.proto to ctx.tun.inner_proto
netfilter: flowtable: rename tun.l3_proto to tun.inner_proto
net: netfilter: add ether_type to net_device_path_ctx and use it
net: pass net_device_path_ctx to dev_fill_forward_path()
netfilter: add DEBUG_NET_WARN_ON_ONCE to skb_set_nfct()
====================
Link: https://patch.msgid.link/20260810194015.932627-1-pablo@netfilter.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
