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>
The LG VL600 RX path can assemble one device frame from multiple USB RX
URBs. In the single-URB case, the input skb passed by usbnet is also the
buffer being parsed, so @skb and @buf point to the same skb.
When a frame is completed from current_rx_buf, however, @buf points to
the assembled skb while @skb still points to the last URB fragment.
vl600_rx_fixup() returns @buf to the network stack in that path, but it
currently obtains the Ethernet header from @skb.
As a result, the source/destination address fixups and the IPv6 ethertype
fixup can be applied to the final fragment instead of the assembled skb
that is actually delivered. Use @buf for the Ethernet header so the
fixups are applied to the packet being parsed and returned.
This has likely gone unnoticed because the common single-URB path has
@skb == @buf and therefore behaves correctly.
Cc: stable+noautosel@kernel.org # untested fix to unlikely driver error path
Signed-off-by: Xu Rao <raoxu@uniontech.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/30CC616506DE5BC4+20260810084435.2099229-1-raoxu@uniontech.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since removal of the legacy tunnel port types, there are no more
users for these functions outside the main openvswitch module.
Functions to register vport_ops are also not exported. Allocating
vports without operations doesn't make a lot of sense.
Highlighted by Sashiko as a follow up to the removal of the module
infrastructure.
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Reviewed-by: Aaron Conole <aconole@redhat.com>
Link: https://patch.msgid.link/20260812122007.457136-1-i.maximets@ovn.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The ovskey flow-string parser has no OVS_KEY_ATTR_SCTP entry, so a
flow string containing sctp(src=.../dst=...) parses without error but
silently drops the L4 key. The resulting flow carries only
ipv4(proto=132), and the kernel rejects it: match_validate() in
flow_netlink.c requires OVS_KEY_ATTR_SCTP when the IP protocol is
IPPROTO_SCTP and returns -EINVAL for the missing key.
Register OVS_KEY_ATTR_SCTP in the parse table and add a matching
selftest that verifies SCTP flow key matching (sctp src/dst port).
One listener serves the whole test. socat's fork option handles each
association in a child, so the flow rules are the only thing that
changes between the three phases and the listener is never restarted
underneath them. -t 1 bounds how long a forked child lingers after
its association closes, and the existing kill -TERM of the captured
pid on teardown removes the listener itself.
Also enable CONFIG_IP_SCTP in the selftest kernel config. The config
checker strips underscores before comparing keys, so the entry sorts
before CONFIG_IPV6 rather than after it.
Signed-off-by: Minxi Hou <houminxi@gmail.com>
Reviewed-by: Aaron Conole <aconole@redhat.com>
Link: https://patch.msgid.link/20260811181645.1918420-1-houminxi@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
PSGMII (the Qualcomm 5-port SGMII) conveys the link negotiation result
from the PHY back to the MAC through per-channel in-band SGMII words,
exactly like SGMII and QSGMII.
However, PHY_INTERFACE_MODE_PSGMII is missing from
phylink_get_inband_type(), so phylink reports INBAND_NONE for it and
phylink_pcs_neg_mode() falls back to PHYLINK_PCS_NEG_NONE. The PCS is
then programmed in force mode and its control-register speed bits (which
default to 1000base) are used, so a slower copper link - e.g. 100base-T
- is reported as 1Gbps and cannot pass traffic.
Classify PSGMII alongside SGMII and QSGMII as INBAND_CISCO_SGMII so the
PCS negotiates in-band and the resolved link speed comes from the PHY
in-band word.
Also add PSGMII to the generic clause 22 PCS helper functions which
handle the SGMII in-band word. Without this, a PCS using these helpers
would still fall through to the default handling and force the link
state to false in phylink_mii_c22_pcs_decode_state(), fail to encode
the SGMII advertisement, and get rejected by phylink_get_link_timer_ns().
Signed-off-by: Sandeep Sondagar <sandeepsondagar@gmail.com>
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Link: https://patch.msgid.link/20260809-phylink-psgmii-v3-1-908dcd3a9e3d@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The ffs()/fls() guard in ethnl_set_tsconfig() was meant to enforce
that the user selects exactly one tx_type (and one rx_filter)
at a time (off / none are explicit types with non-zero values).
However, both ffs(0) and fls(0) return 0, so the guard passes
a zero-valued bitset through.
The subsequent ffs(req_tx_type) - 1 would produce -1, if user selected
no bit. net_hwtstamp_validate() catches the invalid -1 downstream,
but returns a generic error (-ERANGE) without telling the user
what went wrong. Return -EINVAL + extack instead.
Replace the ffs()/fls() comparison with a hweight32() == 1 check.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Joe Damato <joe@dama.to>
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Link: https://patch.msgid.link/20260812162230.1837788-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
l2tp_tunnel_notify() and l2tp_session_notify() use
genlmsg_multicast_allns(), which delivers to listeners in every network
namespace. l2tp is per-namespace, and a tunnel records the namespace it
belongs to in tunnel->l2tp_net. Each event concerns one namespace, yet
every namespace is told about it. A tunnel event carries the tunnel and
peer tunnel ids, plus the socket's addresses with both ports for a UDP
tunnel. A session event carries the session and peer session ids, the
interface name, plus the L2TP cookies where those are set. A listener
needs no privilege for any of this, because l2tp_multicast_group[]
carries no flags and genl_bind() asks for no capability.
The fix is to send to the tunnel's namespace with
genlmsg_multicast_netns(). Commit 134e63756d ("genetlink: make netns
aware") added both helpers and drew the line between them. The netns
variant is for an object that lives in a namespace.
I found this by auditing the tree's six genlmsg_multicast_allns() call
sites for objects that live in a network namespace. Only the two l2tp
ones do.
I reproduced it on net at dd057113ac, in a virtual machine, with no
real hardware involved. A process in the initial namespace, running as
an ordinary user with an empty capability set, receives the create and
delete events of a tunnel. The tunnel was set up inside an unprivileged
user and network namespace. tools/testing/selftests/net/l2tp.sh passes
before and after.
On a container host, any local user and every other tenant can read a
tenant's tunnel parameters.
Cc: stable+noautosel@kernel.org # high regression risk
Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260809094252.2107242-1-maoyixie.tju@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Xuanqiang Luo says:
====================
net: phy: dp83640: fix shared clock lifetime and probe error cleanup
The DP83640 driver shares one PTP clock between all PHYs on the same MII
bus.
Its driver-local clock lookup and removal scheme can leak the shared clock
on probe failure or free it while another probe is acquiring it.
This series moves the shared clock to the PHY package infrastructure.
Patch 1 adds PHY package locking helpers.
Patch 2 embeds the pin configuration in the shared clock.
Patch 3 clears per-PHY state when PTP clock registration fails.
Patch 4 fixes the shared clock lifetime using the PHY package
infrastructure.
====================
Link: https://patch.msgid.link/20260811151345.73582-1-xuanqiang.luo@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Commit 42e2a9e11a ("net: phy: dp83640: improve phydev and driver
removal handling") moved per-bus clock cleanup from module exit to the
remove path. This leaves two lifetime problems.
dp83640_clock_get_bus() publishes a newly allocated clock before the
driver allocates its per-PHY data and registers the PTP clock. If either
operation fails, no PHY is bound and the remove callback cannot release
the clock, leaking the clock and the MII bus device reference.
The remove path can also free a clock after dropping clock_lock. A
concurrent probe may already have found the clock under
phyter_clocks_lock and be waiting for clock_lock, allowing it to acquire
a freed mutex and access the freed clock.
Use the PHY package infrastructure for the per-bus clock. PHY packages
are tracked per MII bus, and the driver uses BROADCAST_ADDR as the
package key so the DP83640 PHYs on the same bus share the same clock
storage. Call phy_package_join() during probe and phy_package_leave() on
probe errors and in remove.
Serialize the one-time clock initialization with the package lock because
phy_package_probe_once() elects an initializer but does not wait for
initialization to finish.
Cc: stable+noautosel@kernel.org # untested fix to a driver init path
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Link: https://patch.msgid.link/20260811151345.73582-5-xuanqiang.luo@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
