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>
dp83640_probe() publishes its per-PHY state through phydev before
registering the PTP clock. If registration fails, the private data is
freed while phydev->mii_ts and phydev->priv still point to it, and
default_timestamp remains set.
Clear the published PHY state and reset the PTP clock pointer before
freeing the private data.
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-4-xuanqiang.luo@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The DP83640 has a fixed number of PTP pins, and its pin configuration
has the same lifetime as the per-bus clock. Allocating the configuration
separately adds an allocation failure path and requires a separate free.
Embed the pin configuration in struct dp83640_clock and point the PTP
clock information at the embedded array. This changes only the storage;
the pin functions remain configurable at runtime. It also allows all
per-bus clock storage to be managed as one allocation.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Link: https://patch.msgid.link/20260811151345.73582-3-xuanqiang.luo@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The PHY package API provides private data shared by all PHYs in a
package. Drivers are responsible for synchronizing access to this data,
but the API does not provide a lock for that purpose.
Add phy_package_lock() and phy_package_unlock() for drivers to serialize
access to package-private data, including its initialization.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Link: https://patch.msgid.link/20260811151345.73582-2-xuanqiang.luo@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This reverts commit 13b7e6a96a.
That commit made mt76_dma_cleanup() disable every RX NAPI instance before
deleting it, to silence WARNs in __netif_napi_del_locked() and
page_pool_disable_direct_recycling() seen when unloading mt7915e with an
MT7916.
On mt7921e and mt7925e the same instances are already disabled earlier,
in mt7921e_unregister_device() and mt7925e_unregister_device(), which
only afterwards call mt792x_dma_cleanup() -> mt76_dma_cleanup(). Each
instance is therefore disabled twice, and napi_disable() is not
idempotent: on return it leaves NAPIF_STATE_SCHED and NAPIF_STATE_NPSVC
set, so the second call spins in usleep_range() forever, waiting for bits
that nobody will clear.
mt7921_pci_shutdown() and mt7925_pci_shutdown() reuse the remove path, so
this is hit on every reboot, poweroff and module unload. It is silent:
the stuck task keeps sleeping and rescheduling, so neither the hung task
detector nor the lockup detectors fire, and the last line on the console
is "systemd-shutdown[1]: Rebooting."
task:modprobe state:D stack:25720 pid:7954 tgid:7954
Call Trace:
<TASK>
__schedule+0x11b8/0x26d0
schedule+0xe7/0x2f0
schedule_hrtimeout_range_clock+0x218/0x330
usleep_range_state+0x133/0x1b0
napi_disable_locked+0x37d/0x5f0
napi_disable+0x43/0x80
mt76_dma_cleanup+0x2b4/0x860 [mt76]
mt7921_pci_remove+0x17f/0x350 [mt7921e]
pci_device_remove+0xb6/0x1e0
device_release_driver_internal+0x38d/0x540
driver_detach+0xd0/0x1b0
bus_remove_driver+0x127/0x2d0
pci_unregister_driver+0x2a/0x280
__do_sys_delete_module+0x36a/0x5b0
do_syscall_64+0x11c/0x6d0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
</TASK>
Dropping the two driver-side loops instead was tried and rejected: with
them gone, the RX poll can reach mt76_token_release() via
PKT_TYPE_TXRX_NOTIFY and mt7921_mac_tx_free() while
mt76_connac2_tx_token_put() is running idr_destroy(&dev->token) outside
token_lock, which is a use-after-free rather than a hang [1].
Revert for now, so that reboot, poweroff and module unload work again.
The WARNs on mt7915e are a less severe problem than an unbootable
machine, and fixing them belongs in the drivers that delete the NAPI
instances, where each one can pick a point that is safe for its own
teardown order, rather than in the shared mt76_dma_cleanup().
[ This is the "landing soonish" known regression fix mentioned in the
previous networking merge commit - Linus ]
Reported-by: Bert Karwatzki <spasswolf@web.de>
Closes: https://lore.kernel.org/all/20260724151419.26014-1-spasswolf@web.de/
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221818
Link: https://lore.kernel.org/all/20260730050428.GA73812@sol/ [1]
Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Acked-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
Fixes: 13b7e6a96a ("wifi: mt76: Disable napi when removing device")
Tested-by: Devin Wittmayer <lucid_duck@justthetip.ca>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Pull networking fixes from Paolo Abeni:
"Including fixes from netfilter.
There is a known WiFi/mt76 regression, waiting for a complete fix that
should land soonish.
Previous releases - regressions:
- tcp: fix icsk_ack.ato bitfield overflow
- af_unix: Unlink scc_entry in unix_del_edge()
- ipv4: fix use-after-free in fib_nhc_update_mtu()
- netfilter:
- ipset: fix refcount race between list:set GC and swap
- nf_tables_offload: suppress WARN_ON_ONCE for ENOMEM in abort
path
- sched: act_ct: fix sk_buff leak when the header checks reject a
packet
- sctp: clear new_transport when removing a peer
- dibs: correct freeing of dmb_clientid_arr
- ovpn: fix NULL dereference when killing missing key
- eth:
- veth: fix queue index used to wake the peer txq in veth_poll
- ngbe: fix NULL pointer dereference in non-MSI-X interrupt
enabling
- gve: fix zero-length skb frag with header-split
Previous releases - always broken:
- core: fix skb length accounting after generic XDP frag adjustment
- af_packet: don't send zero-byte data in tpacket_snd().
- eth:
- bnxt: avoid deadlock when canceling IRQ affinity notifier
- ipvlan: inherit needed_headroom and needed_tailroom from
phy_dev"
* tag 'net-7.2-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (55 commits)
l2tp: fix tunnel and session refcount leak on seq_file release
net/sched: cls_bpf: reject dev-bound programs bound to a different device
sctp: fix use-after-free of cached ASCONF chunk
net: ethernet: ti: am65-cpsw-nuss: Fix port_id extraction from SRC TAG
sctp: clear new_transport when removing a peer
net/dibs: Correct freeing of dmb_clientid_arr
net/sched: cls_u32: skip hash tables in u32_bind_class()
gve: fix NULL dereference due to missing ptp adjfine
gve: fix zero-length skb frag with header-split
net/sched: act_api: fix TOCTOU NULL deref on a->goto_chain
af_packet: Don't send zero-byte data in tpacket_snd().
tipc: read le->link under the node lock in tipc_node_link_down()
selftests: tls: cover splice after a failed decrypt
net/tls: Fail tls_sw_splice_read() after a failed async decrypt
net: ngbe: fix NULL pointer dereference in non-MSI-X interrupt enabling
net: tap: fix wrong transport_header when sending VLAN-tagged frame
net: packet: fix wrong transport_header when sending VLAN-tagged frame
vxlan: do not arm the ageing timer on a device that is down
ipv4: fix use-after-free in fib_nhc_update_mtu()
NTB: ntb_netdev: Preserve RX queue depth on allocation failure
...
Pull firewire fix from Takashi Sakamoto:
"Fix a NULL pointer dereference in 1394 OHCI PCI driver when probe()
returns early with an error, as detected by Syzkaller"
* tag 'firewire-fixes-7.2-final' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394:
firewire: ohci: fix NULL pointer dereference in ar_context_release
Pull gpio fixes from Bartosz Golaszewski:
- use raw_spinlock_t in gpio-ml-ioh to avoid locking context issues
- fix a race condition in gpio-ml-ioh by sharing the register locks
across channels
- fix a use-after-free bug in unbind path in gpio-sloppy-logic-analyzer
* tag 'gpio-fixes-for-v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
gpio: sloppy-logic-analyzer: fix use-after-free via debugfs trigger on unbind
gpio: ml-ioh: share the register lock across channels
gpio: ml-ioh: use raw_spinlock_t for the register lock
gpiolib: Check gc->get_direction() before calling gpiod_get_direction()
Pull m68k fix from Geert Uytterhoeven:
"Define NR_CPUS to 1.
This fixes a long-standing but never critical before oddity on m68k,
that turned into a serious configuration issue after a recent erofs
change"
* tag 'm68k-for-v7.2-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k:
m68k: Define NR_CPUS to 1
Breno Leitao says:
====================
netconsole: replace target_list_lock by RCU on userdata hot path
I would like to move netconsole to use RCU on the hot path for
a while instead of target_list_lock. My goal is to have no lock on the
tx side at all and eventually drop CON_NBCON_ATOMIC_UNSAFE, if that is
possible [1].
Start removing target_list_lock on certain parts of the code. This patch
transforms the userdata array into a RCU-protected pointer, and uses the
dynamic mutex as the write lock.
Added a selftest, given we didn't have any netconsole selftest for
userdata operations. Feel free to drop it if this is not useful, dear
maintainers.
Link: https://lore.kernel.org/all/20251121-nbcon-v1-0-503d17b2b4af@debian.org/[1]
Signed-off-by: Breno Leitao <leitao@debian.org>
====================
Link: https://patch.msgid.link/20260810-netcons-userdata-rcu-v3-0-f65557f769ce@debian.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
update_userdata() takes target_list_lock to swap nt->userdata and
nt->userdata_length, then frees the old buffer. Since commit
7eab73b186 ("netconsole: convert to NBCON console infrastructure")
that lock is also the console's device_lock, so writing a userdata value
from configfs serialises against the printk core emitting messages.
The buffer is immutable once published, which is what RCU is for. Move
the string and its length into a single netcons_userdata object and
publish it with rcu_replace_pointer(), freeing the old one with
kfree_rcu().
New userdata design:
0) Unify the userdata fields into a struct netcons_userdata
1) update_userdata() no longer needs target_list_lock.
2) writers stay serialised by dynamic_netconsole_mutex.
3) reading userdata needs an RCU read lock.
No functional change intended.
Signed-off-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Gustavo Luiz Duarte <gustavold@gmail.com>
Link: https://patch.msgid.link/20260810-netcons-userdata-rcu-v3-1-f65557f769ce@debian.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
During the error handling path of the driver's probe function, a NULL
pointer dereference can occur in ar_context_release().
When pci_probe() fails early (e.g., if pcim_enable_device() or MMIO mapping
fails), the devres cleanup mechanism invokes release_ohci(). This function
unconditionally calls ar_context_release() to clean up the asynchronous
receive contexts. However, if ar_context_init() was not yet called,
ctx->ohci remains NULL (as the fw_ohci structure is zero-initialized by
devres_alloc()).
ar_context_release() immediately dereferences ctx->ohci to get the dev
pointer before checking if the context was actually initialized, leading to
a crash:
Oops: general protection fault, probably for non-canonical address
0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
RIP: 0010:ar_context_release+0x3f/0x380 drivers/firewire/ohci.c:543
Call Trace:
release_ohci+0x3f/0x60 drivers/firewire/ohci.c:3567
release_nodes drivers/base/devres.c:546 [inline]
devres_release_all+0x1a8/0x260 drivers/base/devres.c:576
device_unbind_cleanup drivers/base/dd.c:597 [inline]
really_probe+0x451/0xae0 drivers/base/dd.c:772
To fix this, move the assignment of the dev pointer after the !ctx->buffer
check. If ctx->buffer is NULL, it indicates that the context was never
successfully initialized and there is nothing to release, safely avoiding
the dereference of the uninitialized ctx->ohci pointer.
Fixes: 5716e58aec ("firewire: ohci: release buffer for AR req/resp contexts when managed resource is released")
Assisted-by: Gemini:gemini-3.5-flash Gemini:gemini-3.1-pro-preview syzbot
Reported-by: syzbot+d30aad27833a559defab@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=d30aad27833a559defab
Link: https://syzkaller.appspot.com/ai_job?id=10a18617-7893-42dd-bf1c-cd49e19e95d9
Signed-off-by: Aleksandr Nogikh <nogikh@google.com>
Link: https://lore.kernel.org/r/90c5db71-dd1f-4d46-b9d3-2f1046cbd5ea@mail.kernel.org
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Aditya Garg says:
====================
net: mana: Avoid DMA queue allocation failure under memory fragmentation
The MANA driver can fail to bring up its queues on systems with high
memory utilization because every GDMA queue ring is allocated as a
single dma_alloc_coherent() of the whole power-of-2 ring size. Under
memory fragmentation these high-order allocations may fail, preventing
the driver from creating queues when opening the interface, after a VF
reset, or when reconfiguring channels, ring parameters or MTU.
Per-queue sizes that are problematic, with depth and size given as
(default, max) over the ethtool ring settings:
ring entry depth size
------------------------------------------------------------
TX completion queue 64 B (256, 16384) (16 KB, 1024 KB)
TX send queue 32 B (256, 16384) ( 8 KB, 512 KB)
RX completion queue 64 B (1024, 8192) (64 KB, 512 KB)
RX receive queue 32 B (1024, 8192) (32 KB, 256 KB)
event queue 16 B 2048 (fixed) 32 KB
This series addresses the issue by:
1. Routing all CPU-side ring access through mana_gd_ring_ptr() and
mana_gd_ring_contig_avail(). On a contiguous ring these reduce to
simple arithmetic, so this patch is a pure refactor.
2. Falling back in mana_gd_alloc_memory() to a vector of scattered
order-0 coherent pages when the contiguous allocation fails. The
device sees the same page-list format either way, as
mana_gd_create_dma_region() already describes a ring as a list of
MANA_PAGE_SIZE addresses. The HW channel stays contiguous, as
advertising a scattered page list needs the HW channel itself.
Throughput testing confirms no regression. Since the fallback only
triggers under memory fragmentation, the scattered-page path was enabled
unconditionally for all eligible GDMA queue rings during testing (iperf3,
Gbit/s):
Baseline Patched Patched
Connections Contiguous Contiguous Scattered
-----------------------------------------------
1 46.1 46.2 46.1
16 182 182 182
32 182 182 182
64 182 182 182
====================
Link: https://patch.msgid.link/20260807210002.1695263-1-gargaditya@linux.microsoft.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Each GDMA queue ring is one dma_alloc_coherent() of the whole ring size.
Such high-order allocations fail first under memory fragmentation, so
queue setup can fail with memory still free.
The hardware does not need the ring physically contiguous:
mana_gd_create_dma_region() already maps it as a list of MANA_PAGE_SIZE
(4K) device addresses. Only the driver's linear CPU view needs
contiguity, and it goes through mana_gd_ring_ptr() and
mana_gd_ring_contig_avail(); change both to map offsets onto
scattered pages.
Add a fallback in mana_gd_alloc_memory(): data-path queues pass
allow_scatter=true, so when the contiguous allocation fails the ring is
backed by a vector of scattered PAGE_SIZE (order-0) coherent pages,
presenting the same DMA page-list layout to the device. The HW channel
bootstrap keeps allow_scatter=false, and the debugfs ring dumper reads
scattered rings through the same helpers.
Signed-off-by: Aditya Garg <gargaditya@linux.microsoft.com>
Link: https://patch.msgid.link/20260807210002.1695263-3-gargaditya@linux.microsoft.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
In preparation for backing GDMA queue memory with a vector of
non-contiguous order-0 coherent pages, route CPU access to a queue's
ring buffer through two new helpers: mana_gd_ring_ptr() returns the CPU
address of a byte offset into the ring, and mana_gd_ring_contig_avail()
the number of bytes left before the ring wraps, so a WQ write that runs
past the end of the ring can be split at that point.
Convert the EQ, CQ and work-request paths to use them.
mana_gd_write_sgl() now takes a byte offset rather than a raw pointer,
so mana_gd_post_work_request() derives the SGL position arithmetically.
While queue memory is contiguous both helpers are simple arithmetic on
the ring base and size, so there is no functional change.
Signed-off-by: Aditya Garg <gargaditya@linux.microsoft.com>
Link: https://patch.msgid.link/20260807210002.1695263-2-gargaditya@linux.microsoft.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Joel Granados says:
====================
net: sysctl: Const Qualify sysctl ctl_table arrays
What?
=====
We do two things:
1. Reject netns-unsafe: Replace warning and file permission change with
an error (reject registration) when an "unsafe" net sysctl
registration is detected.
2. Const qualify: Const qualify network templated ctl_table arrays and
unconditional kmemdup'ed ctl_table arrays.
Why?
====
The main motivation for this is to continue with the const qualification
of the ctl_table arrays [1]. The permission change inside
ensure_safe_net_sysctl disallows cons qualifiaction as it basically
modifies the entries before running the sysctl registration.
ent->mode &= ~0222;
On reject netns-unsafe?
=======================
* I believe that there is currently now way that the permission change
gets executed [2]
* I found one case where the warning message was posted to lore
(vsock_sysctl_register) [3], but it made its to mainline as part of
the second case in [2].
* We should error anyway because writing to the global sysctl value
through a child netns is indicative of a bug [4].
On Const qualification?
=======================
We can separate the places where network registers sysctl tables into
three groups:
1. Static global: The unchanged global static arrays are passed along to
sysctl register.
2. Always kmemdup: The global static arrays are always kmemdup'ed before
passing them along to sysctl register.
3. Dynamic global: The global static array is changed in place before
passing it along to sysctl register.
This series handles case 1 and 2. It leaves 3 for a later point as
const qualifying those global ctl_tables is more involved.
I would be very thankful if you point me to anything that I have missed
in my analysis that shows that this cannot/shouldn't be done.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/sysctl/sysctl.git/commit/?h=constfy-sysctl-6.14-rc1&id=1751f872cc97f992ed5c4c72c55588db1f0021e1
[2]
I have identified 4 contexts relevant to the ensure_safe_net_sysctl call
inside the network sysctl registration.
1. When the (struct net) == &init_net (like in iw_cm_init): In this case
ensure_safe_net_sysctl is not executed and permission modification
never happens.
2. When the ctl_table data (->data) gets "manually" assigned to
something other init_net (like in vsock_sysctl_register): In this
case ensure_safe_net_sysctl *is* executed but the data that is passed
is neither a module address (!is_module_address) nor a kernel core
address (!is_kernel_core_data); so the permission modification never
happens.
3. When the permissions are explicitly changed on a kmemdup'ed ctl_table
array (like in sysctl_core_net_init): in this case
ensure_safe_net_sysctl *is* executed but the permission modification
never happens as the mode is not writable.
4. When ctl have custom proc_handlers (like in nf_lwtunnel_net_init): In
this case ->data is NULL so it is not a module address
(!is_module_address) nor a kernel core address
(!is_kernel_core_data), so permission modification never happens.
It seems like there is no way of executing the permission change in
ensure_safe_net_sysctl. Please correct me if this is inaccurate and help
me find the case that I missed.
[3]
https://lore.kernel.org/all/20260302194926.90378-1-graf@amazon.com/
[4]
The ensure_safe_net_sysctl function was introduced in Commit:
31c4d2f160 ("net: Ensure net namespace
isolation of sysctls") which states that it is trying to prevent a
leak (indicative of a bug).
[5]
https://patchwork.kernel.org/project/netdevbpf/patch/20260713-jag-net_const_qualify-v3-1-7289fe9eaea6@kernel.org/
====================
Link: https://patch.msgid.link/20260810-jag-net_const_qualify-v4-0-77e888237c69@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Replace the warning and file permission change with an error when an
"unsafe" net sysctl registration is detected.
One of the barriers preventing the const qualification of the ctl_tables
in the net directory is the permission (->mode) change in
ensure_safe_net_sysctl. This prep commit removes that barrier and
ensures that the received ctl_table pointer to the net ctl_table
register function is const.
Signed-off-by: Joel Granados <joel.granados@kernel.org>
Link: https://patch.msgid.link/20260810-jag-net_const_qualify-v4-1-77e888237c69@kernel.org
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The commit that introduced the receive-path latency trace added the
clearing of inc->i_rx_lat_trace[] to rds_inc_init() only;
rds_inc_path_init() never got it.
That asymmetry matters for the one caller that reuses memory:
rds_tcp_data_recv() carves its rds_tcp_incoming out of a kmem_cache
with no zeroing and no constructor, so after rds_inc_path_init() the
array still holds the timestamps of whatever message previously
occupied that slab object. No stale value is user-visible today -
every message that reaches the socket happens to overwrite all four
slots (RX_HDR at allocation, RX_START when the header completes,
RX_END at delivery, RX_CMSG at recvmsg time) before
RDS_CMSG_RXPATH_LATENCY reads them back as deltas - but that is a
property of the current writers, not of the init contract, and a
future trace point or an early-exit path would expose another
message's timestamps to userspace.
Clear the array in rds_inc_path_init() too, so both init helpers
leave the inc fully initialized. memset is the form the clearing
already takes on the rds_inc_init() side since commit 1635bb548f
("net: rds: use memset to optimize the recv"). Hardening only; no
user-visible bug in the current code.
Assisted-by: Claude-Code:claude-fable-5
Signed-off-by: Allison Henderson <achender@kernel.org>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260810055631.299558-1-achender@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
