Add four new test cases that validate coalescing
under increased size limits (BIG TCP):
big_tcp_data_same
- validates that equal-sized segments coalesce past
the legacy IP_MAXPACKET limit.
big_tcp_data_lrg_sml
- validates that a smaller final segment coalesces into the
previous chain of large-sized segments while crossing the
IP_MAXPACKET limit.
big_tcp_tcp_seq
- validates that a packet with a wrong sequence number doesn't
coalesce. The test uses a sequence number for which the low 16 bits
correspond to the correct sequence number to validate against
truncation bugs, since total aggregate length crosses over the
legacy size limit for BIG TCP.
big_tcp_large_max
- validates that coalescing stops at the configured BIG TCP limit.
Use a gro_flush_timeout value 2x higher for the BIG TCP test cases
to prevent under-coalescing.
Signed-off-by: Narcisa Vasile <narcisav.kernel@gmail.com>
Link: https://patch.msgid.link/20260913052419.77910-1-narcisav.kernel@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
socketpair() writes the reserved descriptor numbers to userspace before
creating the sockets and their file objects. A later failure therefore
leaves a modified caller's array despite returning an error, contrary to
POSIX. For example, socketpair(AF_UNIX, SOCK_STREAM, -1, fd) returns
EPROTONOSUPPORT but replaces the array's sentinel values with unused fd
numbers.
Defer the output stores until both file objects have been created, before
installing either descriptor. If a store faults, drop both file references
before releasing the reserved descriptor slots. Keep the early descriptor
reservation and the existing setup-failure cleanup paths.
In practice, I doubt anyone notices. But this aligns with the expected
behavior
Signed-off-by: Steve Grubb <sgrubb@redhat.com>
Link: https://patch.msgid.link/JyK226D0S5CWGUpAC4MO4A@redhat.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
NAPI budgets received packets, so gmac_rx() only consumes budget when an
EOF descriptor completes a frame. A malformed descriptor stream without
EOF can consequently make one poll consume the entire snapshotted RX ring,
which may contain up to 32768 descriptors. The error paths can also flood
the kernel log while doing so.
Keep the packet budget EOF-based, but impose a separate descriptor limit
which allows MAX_SKB_FRAGS descriptors for every packet in the budget. If
the limit is reached with descriptors still pending, return the full NAPI
budget to retain ownership and continue in another poll. Ratelimit errors
reported from malformed descriptor paths.
Signed-off-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260914-b4-gemini-ethernet-fixes-2-v2-2-5ab39a047b90@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
macsec_changelink() operates on two netns: dev_net(dev) and the netns
of macsec->real_dev. They differ once the macsec device is created in
or moved to a netns other than the one holding the real device. The
rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so
a caller privileged there but not in dev_net(real_dev) can reach
real_dev's driver:
- IFLA_MACSEC_OFFLOAD -> macsec_update_offload(), which calls
ops->mdo_add_secy() / mdo_del_secy() on real_dev.
- the tail "propagate to the device" block, which calls
ops->mdo_upd_secy() on real_dev for any request against an already
offloaded device that does not change the offload mode. This one
needs no IFLA_MACSEC_OFFLOAD attribute at all.
Gate both with rtnl_dev_link_net_capable(), as the tunnel, geneve,
vxlan and macvlan handlers already do. It fires only when the request
would reach real_dev: when IFLA_MACSEC_OFFLOAD asks for a mode other
than the current one, or when the device is already offloaded. The
local attributes of a non-offloaded device stay configurable from its
own netns.
The check is in the changelink handler rather than in
macsec_update_offload(), because the mdo_upd_secy() propagation does
not go through that function. Its other caller, macsec_upd_offload()
for MACSEC_CMD_UPD_OFFLOAD, is GENL_ADMIN_PERM. The ndo and dellink
paths that reach real_dev's driver as a side effect of operating the
macsec device itself (open/stop, set_mac_address, dellink) are
unchanged here.
rtnl_dev_link_net_capable() was added by commit 8165f7ff57 ("net:
ip_gre: require CAP_NET_ADMIN in the device netns for changelink"); a
stable tree without it needs that first.
Cc: stable+noautosel@kernel.org # high regression risk; local DoS by userns are a dime a dozen
Fixes: 3cf3227a21 ("net: macsec: hardware offloading infrastructure")
Cc: Antoine Tenart <atenart@kernel.org>
Signed-off-by: Aamir Ahmed <elb12345@hotmail.co.uk>
Link: https://patch.msgid.link/AS8P251MB000176E827636EA185226908C8BE2@AS8P251MB0001.EURP251.PROD.OUTLOOK.COM
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jumbo packets need two bits that default to off, extended packet length in
the auxiliary control register and PCS transmit FIFO elasticity in the
extended control register. The latter raises the transmit limit from 4.5
KB to 9 KB at the cost of 16 ns of 1000BASE-T transmit latency, and the
two together take copper mode to 10 KB.
Without them such frames are lost on a 100M link while the same frames
pass at 1G. On a Raspberry Pi CM5, which uses a BCM54210PE, 9142 byte
frames at 100M are lost 20 out of 20 with the MAC counting every one
as transmitted. The same frames over the same path at 1G arrive intact.
Set both, which bcm_phy_enable_jumbo() already does for bcm7xxx. The
frames then arrive and the payloads check out byte for byte.
Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://patch.msgid.link/20260914094703.1093504-1-nb@tipi-net.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The fixed-rate clock is registered with clk_register_fixed_rate(), but
its error and removal paths use clk_unregister(). That unregisters the
clock without freeing the fixed-rate provider allocation.
Use clk_unregister_fixed_rate() on lookup creation failure, later PHY
initialization failure and removal to release the provider allocation as
well. Keep the existing clock registration and lookup cleanup ordering.
This issue was identified during our ongoing static-analysis research while
reviewing kernel code.
Cc: stable+noautosel@kernel.org # untested fix to a driver init path
Co-developed-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260911155318.88857-1-mhun512@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jakub Kicinski says:
====================
psp: correct notifications and device info around device assoc
We recently added the ability to associate a HW PSP device with
a software device like netkit or veth to be able to make PSP
usable from containers. This stretches the visibility of a PSP
device to multiple netns's.
Correct two minor issues:
[Patch 2] skip reporting the main ifindex in remote netns. I'm not sure
if we had some justification for this but looking back it's pretty
confusing. The ifindex is meaningless in another netns, better
not to have it.
[Patch 4] correct the change notification when net_device is removed.
The "leaving" notification had the removed netdev still listed among
the associated devices. This made the code simpler but really it makes
the notification impossible to interpret. Add the extra code to handle
this right, exclude the removed device, and send a del notification
when last device in a netns is chopped off.
Both of these were discovered by an LLM scan of the YAML spec,
the spec itself appears to not have major bugs.
====================
Link: https://patch.msgid.link/20260912200426.121025-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The main namespace must see a change which no longer lists the device,
and the namespace which lost its last association must see the device
go away. Check that on both paths which generate the notifications,
dev-disassoc and netdevice removal, and check that a namespace which
still has another association is only told about the change.
Reviewed-by: Daniel Zahka <daniel.zahka@gmail.com>
Link: https://patch.msgid.link/20260912200426.121025-7-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The netkit removal test builds a disposable netkit pair and moves its
peer into the test namespace. The next commit needs a second associated
device there, so move that to a helper. No functional change, other
than looking the new peer up among all netkit devices rather than the
two the environment created, which is what makes it reusable.
Reviewed-by: Daniel Zahka <daniel.zahka@gmail.com>
Link: https://patch.msgid.link/20260912200426.121025-6-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The dev-change-ntf generated by dev-disassoc was built before the
association was unlinked, so the assoc-list it carried still contained
the device which was going away, and nothing corrected it afterwards.
We don't really expect associations to change during a lifetime of
a netns but this is still wrong. Netlink listeners need to be able
to tell the current "state of the world" based on notifications.
The notification had to be sent early because psp_nl_multicast_per_ns()
derives the set of namespaces to notify from the association list, so
a namespace losing its last associated device becomes unreachable once
the entry is gone. In that case - get the netns from the netdev itself,
and send that namespace a dev-del-ntf. If the netns had multiple
associated netdevs and only one disassoc'd we'll still send a change
notification, just with a correct list.
Reviewed-by: Daniel Zahka <daniel.zahka@gmail.com>
Link: https://patch.msgid.link/20260912200426.121025-5-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
dev-get must not report the ifindex outside of the main netns.
The dev-get checks for an associated namespace are already there,
add the "no main ifindex" assertion.
Reviewed-by: Daniel Zahka <daniel.zahka@gmail.com>
Link: https://patch.msgid.link/20260912200426.121025-4-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
PSP device is visible in a netns if any of the devices (eg. netkit)
are associated with that PSP device. In the main netns we show
all the associated netdevs + their netns id. In the "container"
netns we show only the local devices. But we were listing the main
netdev in all cases, even though it's meaningless outside of
the main netns.
Report ifindex only in the main netdevice's namespace. Absence is
already unambiguous, the by-association flag is set exactly in the
messages which no longer carry the ifindex.
Reviewed-by: Daniel Zahka <daniel.zahka@gmail.com>
Link: https://patch.msgid.link/20260912200426.121025-3-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Fix ruff 0.16 warnings:
C403 Unnecessary list comprehension (rewrite as a set comprehension)
Reviewed-by: Daniel Zahka <daniel.zahka@gmail.com>
Link: https://patch.msgid.link/20260912200426.121025-2-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The hardware provides valid HWC destination vRQ and vRCQ IDs for all PFs
and VFs. Use these IDs unconditionally in mana_hwc_send_request(), as
the PF-specific gate is not required.
Signed-off-by: Manish Awasthi <mawasthi@linux.microsoft.com>
Reviewed-by: Long Li <longli@microsoft.com>
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Link: https://patch.msgid.link/20260910014427.54272-1-mawasthi@linux.microsoft.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
ql3xxx_probe() enables the PCI device and balances that reference on
probe failure. However, ql3xxx_remove() releases the mappings and PCI
regions without disabling the device, leaving the enable reference
held after unbind.
Add pci_disable_device() at the end of ql3xxx_remove() to balance the
successful probe's pci_enable_device() call. Keep the existing manual
cleanup and probe error handling unchanged.
This issue was identified during our ongoing static-analysis research while
reviewing kernel code.
Cc: stable+noautosel@kernel.org # untested fix to unlikely driver error path
Co-developed-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260913204534.53825-1-mhun512@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
setup_shmem_window() acquires a PCMCIA memory window using
pcmcia_request_window(). If pcmcia_map_mem_page() or the subsequent
ioremap() fails, the function returns without releasing the requested
window.
pcnet_config() treats shared-memory setup failure as non-fatal and falls
back to setup_dma_config(). Probe can therefore continue while socket
window 3 and its reserved iomem range remain unnecessarily held for the
rest of the bound lifetime of the device. pcmcia_disable_device()
eventually releases the window during teardown.
Route error paths after a successful request through a new release label
that calls pcmcia_release_window(). Fold the existing buffer-verification
cleanup into the same path, keeping iounmap() before the window release
when a mapping exists. Leave the request failure path unchanged.
This issue was identified during our ongoing static-analysis research while
reviewing kernel code.
Cc: stable+noautosel@kernel.org # untested fix to unlikely driver error path
Co-developed-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Link: https://patch.msgid.link/20260913204104.53408-1-mhun512@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Firmware execution routine unconditionally uses phy_modify_mmd() for
all OP_WRITE entries which introduces an unnecessary read transaction
when updating an entire 16-bit register. So we optimize this by
checking bitmask boundaries. Use phy_write_mmd() directly to speed up
firmware loading process.
Benchmark number from tracing MDC/MDIO hardware transactions during
firmware loading process:
- Unpatched: about 28,000 MDIO transactions
- Patched: about 9,600 MDIO transactions
This results in an approx 65% reduction in MDIO traffic.
Signed-off-by: Javen Xu <javen_xu@realsil.com.cn>
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260911094527.1928-1-javen_xu@realsil.com.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Paolo pointed out an issue flagged at low priority by Sashiko -
we're currently not handling BE{16,32} attributes in policy dumps.
Commit 3f4285d741 ("netlink: specs: fou: local-v4 and peer-v4 are big
endian") flipped two fou attributes from NLA_U32 to NLA_BE32.
This made them vanish from the policy dump.
Follow the YAML spec format and treat byte order as a property of
a u16 / u32 rather than a type of its own. I don't have a strong
preference either way. The YNL format "feels cleaner" but the
kernel's separate type is easier when handling decoding.
I don't think that the policy type is actually usable for decoding
(since it only contains input types) so I went with YNL and added
the separate attr.
A missing byte order means host order, again like in the YAML specs.
Link: https://lore.kernel.org/ab90f970-0ebb-4c07-b7b1-db3f91395116@redhat.com
Link: https://patch.msgid.link/20260912202401.141336-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Correct indentation in the examples to consistent 2- or 4-spaces
indentation to fix dt-check-style warnings ("example 0
[indent-consistent] indent mismatch ..."). Preferred is 4-spaces, but
re-indenting entire example just for that is too much churn.
In cortina,gemini-ethernet.yaml also drop the wrongly indented mdio bus,
because it is not necessary for the example.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Acked-by: Alex Elder <elder@riscstar.com>
Link: https://patch.msgid.link/20260914155645.112508-2-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
There were duplicate definitions of the enabled_set_xdp and set_xdp
test methods. The two enabled_set_xdp copies were identical apart from
a comment and whitespace.
The set_xdp copies differed by a reset of the hds configuration.
commit ee3ae27721 ("selftests: drv-net: hds: restore hds settings")
introduced the config reset, but this was shadowed by the copy.
Signed-off-by: Dimitri Daskalakis <daskald@meta.com>
Link: https://patch.msgid.link/20260911224255.3675903-1-dimitri.daskalakis1@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The kernel-doc comment of page_pool_free_va() refers to
page_pool_allo_va, which does not exist. The name is page_pool_alloc_va.
Say page_pool_alloc_va.
The wrong name came in with commit 8ab32fa1c7 ("page_pool: update
document about fragment API").
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Link: https://patch.msgid.link/20260912060019.39902-1-kmehltretter@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
devmem.py fails on the HW runners with:
CMD[remote]: dd if=/dev/zero bs=512 count=1 2>/dev/null | socat -b 512 \
-u - TCP6:[fd00:2::1]:50051,bind=[fd00:2::2]:50051,nodelay
STDERR: socat[41018] W bind(5, {AF=10 [fd00:2::2]:50051}, 28): \
Address already in use
ncdevmem installs a 5-tuple flow rule which matches the source port, so
socat has to bind it explicitly. The port comes from rand_port(), which
checks availability on the DUT - but we bind on the remote...
That said the failure rate seems to high to be random collisions
(~2% per sub-test). It's probably TIME_WAIT sockets on the remote,
run_rx_hds() alone creates 12 of them.
Set reuseaddr so a TIME_WAIT socket does not fail the bind. Collisions
with a live socket are still possible, we'll see if they are frequent
enough to care.
Reviewed-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Bobby Eshleman <bobbyeshleman@meta.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Link: https://patch.msgid.link/20260912203101.153688-1-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
All four RTT attributes tell the reader to left-shift, which inflates the
value by 16 to 64 times, and the two usec ones say the result is in msecs.
The attributes carry srtt_us and mdev_us, which hold 3 and 2 fractional
bits. The shift to get the integer part would be a right shift.
Drop the instructions instead of turning them around. The number of
fractional bits is the part worth documenting, whether to shift, divide or
convert to a double is up to the caller.
While at it fix the acronym on the two variance attributes.
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Link: https://patch.msgid.link/20260912234337.308298-2-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
TCP_FASTOPEN_COOKIE_MAX is the longest cookie we accept, not the shortest
one. Cookies are even sized, from 4 bytes up, and the ones Linux itself
generates are 8 bytes, so a 16 byte minimum declares all but the longest
cookie invalid. The reference policy kept under #if 0 in tcp_metrics.c
spells it as a maximum, which is what .len means for NLA_BINARY.
The IPv6 addresses err the other way. The policy uses
NLA_POLICY_EXACT_LEN() for both, so a request carrying a longer address is
rejected with -ERANGE, even though the spec advertises 16 bytes as a mere
minimum. Were the policy generated from this spec, as kernel-policy: global
promises, the check would turn into NLA_POLICY_MIN_LEN() and start
accepting over-long addresses, of which nla_get_in6_addr() would take the
first 16 bytes.
Nothing generated changes. fopen-cookie is reply-only so it never gets a
policy entry, and exact-len only feeds the policy (and the fixed size array
form, which needs a sub-type).
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Link: https://patch.msgid.link/20260912234337.308298-1-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Commit a4d258036e ("tcp: Fix race in tcp_poll") added smp_rmb() in
tcp_poll() and smp_wmb() in tcp_reset() (now tcp_done_with_error())
to ensure that if tcp_poll() observed socket closure, it would also
observe sk->sk_err.
Currently, tcp_poll() unconditionally executes smp_rmb() at the end
of every invocation, which on weakly-ordered architectures such as ARM64
emits a memory barrier instruction (dmb ishld) on the poll fast path,
even for healthy, active sockets.
However, tcp_poll() only needs this barrier if socket closure has been
observed, to ensure that the error code set by tcp_done_with_error()
before socket closure is visible before returning EPOLLERR.
Move smp_rmb() inside the conditional block handling socket closure
(shutdown == SHUTDOWN_MASK || state == TCP_CLOSE). For healthy
connected sockets in epoll, tcp_poll() avoids the barrier entirely.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260913123224.762935-1-edumazet@google.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
ip_tunnel_delete_net() iterates ip_tunnel devices whose link_net
is dying and queues them for destruction.
The devices may reside in different netns.
Let's use unregister_netdevice_queue_net() to support per-netns
device unregistration.
Even after ip_tunnel_delete_net() queues a cross-netns ip_tunnel
device, ip_tunnel_changelink(), ip_tunnel_dellink(), and
ip_tunnel_ctl() could be called concurrently for it (once RTNL is
removed). In such a case, __rtnl_net_unlock() will perform the
unregistration.
Also, ip_tunnel_ctl() needs to check check_net(t->net), otherwise
it could create a new dev in dying netns after ip_tunnel_delete_net().
In the example below, we can see the fallback tunnel device (gre0)
and the cross-netns device (gre1) are unregistered by different
processes:
# bpftrace -e '#include <linux/netdevice.h>
kprobe:ip_tunnel_uninit {
$dev = (struct net_device *)arg0;
printf("PID: %d | DEV: %s%s\n", pid, $dev->name, kstack());
}
kprobe:ipgre_exit_rtnl {
printf("PID: %d%s\n", pid, kstack());
}' &
# ip netns add ns1
# ip netns add ns2
# ip -n ns1 link add name gre1 link-netns ns2 \
type gre local 192.168.0.1 remote 192.168.1.1
# ip netns del ns2
PID: 12
ipgre_exit_rtnl+5
ops_undo_list+702
cleanup_net+1122
process_scheduled_works+2538
...
PID: 12 | DEV: gre0 <------ fallback device (itn->fb_tunnel_dev).
ip_tunnel_uninit+5
unregister_netdevice_many_notify+7129
unregister_netdevice_many_net+1050
__rtnl_net_unlock+37
ops_undo_list+754
cleanup_net+1122
process_scheduled_works+2538
...
PID: 10 | DEV: gre1
ip_tunnel_uninit+5
unregister_netdevice_many_notify+7129
unregister_netdevice_many_net+1050
rtnl_net_work_func+136
process_scheduled_works+2538
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260912230043.2586313-8-kuniyu@google.com
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
struct ip_tunnel.net is the netns where encapsulated packets
flow into.
struct ip_tunnel is linked to ip_tunnel_net.tunnels[] of netns.
During netns dismantle or module unload, ip_tunnel_delete_net()
iterates the list and queues devices for destruction regardless
of the devices' netns.
Thus, once RTNL is removed, the list can be modified concurrently
from different netns due to device removal.
Let's protect it with per-netns mutex.
Note that dev_siocdevprivate() calls netdev_lock_ops() but
it must be NOP for tunnel devices to avoid AB-BA deadlock.
DEBUG_NET_WARN_ON_ONCE() is added to annotate the locking
explicitly.
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260912230043.2586313-7-kuniyu@google.com
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The next patch will introduce per-netns mutex and acquire it
in ip_tunnel_newlink() and ip_tunnel_changelink().
To make the diff cleaner, let's unify the error paths.
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260912230043.2586313-6-kuniyu@google.com
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
With the previous patch, itn->fb_tunnel_dev can be removed
via ->dellink().
However, ioctl(SIOCDELTUNNEL) still uses unregister_netdevice(),
which requires ip_tunnel_del() in ip_tunnel_uninit().
Let's use ip_tunnel_dellink() everywhere to remove ip_tunnel device
and remove ip_tunnel_del() in ip_tunnel_uninit().
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260912230043.2586313-5-kuniyu@google.com
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
ip_tunnel_dellink() ignores itn->fb_tunnel_dev, so the per-netns
fallback tunnel device cannot be removed by userspace.
This also makes default_device_exit_batch() impossible to remove
the device since it calls ->dellink().
So, ip_tunnel_delete_net() has to iterate devices in the dying netns
and call unregister_netdevice_queue() directly.
But then, this duplicates ip_tunnel_del() in ip_tunnel_dellink()
and ip_tunnel_uninit().
Let's set itn->fb_tunnel_dev to NULL in ip_tunnel_delete_net() and
remove for_each_netdev_safe() in ip_tunnel_delete_net().
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260912230043.2586313-3-kuniyu@google.com
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
ipmr.c uses unregister_netdevice() to remove DVMRP tunnel devices
created in ipmr_new_tunnel().
This is fine because currently ip_tunnel_uninit() also calls
ip_tunnel_del() to unlink the device from the hash table.
However, we will move ip_tunnel_del() from ip_tunnel_uninit() to
ip_tunnel_dellink().
Removing DVMRP tunnel devices by unregister_netdevice() would leave
them in the hash table.
Let's call ->dellink for DVMRP tunnel devices.
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260912230043.2586313-2-kuniyu@google.com
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Wei Fang says:
====================
net: enetc: SR-IOV improvements and ENETC v4 VF support
This series enhances SR-IOV support for ENETC v1 and adds VF support
for ENETC v4. For ENETC v1, the trusted VF management and per-VF
configuration query via ndo_get_vf_config() are added. For ENETC v4,
preliminary VF support is introduced for i.MX94 and i.MX95 platforms.
On the PF side, the series introduces trust level management and MAC
address assignment for VFs, and implements ndo_get_vf_config() so that
userspace tools such as 'ip link show' can query the current per-VF
configuration. The PSI-to-VSI messaging infrastructure is extended to
handle link status and link speed queries from VFs, enabling DPDK-owned
VFs to obtain accurate link information from the PF.
On the VF side, MAC address filtering is implemented via the VSI-to-PSI
mailbox, supporting both unicast/multicast hash filters and promiscuous
mode control. Since the ndo_set_rx_mode callback is invoked with BH
disabled and is incompatible with the mailbox polling path,
ndo_set_rx_mode_async is used instead. Link status notifications are also
supported: the VF registers with the PF and receives PSI-to-VSI messages
on every PF link transition, keeping the VF carrier state in sync without
polling.
VF Function Level Reset is handled explicitly to restore the PF-managed
MAC promiscuous policy after each reset, since the hardware default after
FLR enables promiscuous mode regardless of the policy set by the PF
driver.
Several preparatory refactors are included to share infrastructure
between the PF and VF drivers, such as moving msg_task and mac_filter
from struct enetc_pf into the common struct enetc_si.
====================
Link: https://patch.msgid.link/20260909100733.1139689-1-wei.fang@oss.nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Without ndo_get_vf_config(), userspace tools such as 'ip link show'
cannot query the current VF configuration from the PF.
To support this, extend struct enetc_vf_state to track the per-VF VLAN
and spoofchk settings, and update the corresponding setter callbacks to
persist their state when the hardware is programmed.
enetc_pf_get_vf_config() reads back the persisted state and reports MAC
address, VLAN parameters, spoofchk, and trust state through struct
ifla_vf_info.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Link: https://patch.msgid.link/20260909100733.1139689-16-wei.fang@oss.nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Let ENETC v4 VFs track PF link status through the PSI-to-VSI messaging
channel. Add two enetc_si_ops hooks, vf_reg_link_status_notifier and
vf_unreg_link_status_notifier, populated only in enetc4_vsi_ops; rev1
hardware is unaffected.
A dedicated MSI-X vector on the VF handles incoming PSI-to-VSI messages.
Its handler schedules a work item on an ordered workqueue that reads the
notification via VSIMSGRR, updates the carrier state and sets congestion
mode from the PF TX PAUSE state in the message. Reading VSIMSGRR also
acknowledges the PF so it can send the next message. The workqueue is
set up in enetc_vf_probe() and torn down in enetc_vf_remove().
On a VF, enetc_phylink_connect() registers the notifier with the PF and
enetc_close() unregisters it. On registration the PF immediately sends
the current link status and then broadcasts every later transition; if
registration fails, fall back to the LS1028A behaviour and assert
carrier unconditionally. Register the notifier only after the Tx/Rx
resources are allocated in enetc_open(), because once registered the PF
may queue si->msg_task via a link-up message. An error unwind cannot
drain that work item, since enetc_open() and the work item both take the
RTNL lock and waiting would deadlock; and as __LINK_STATE_START is set
before ndo_open() runs, netif_running() stays true during the unwind, so
the queued work could still call netif_carrier_on() and leave carrier
'on' after a failed open.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Link: https://patch.msgid.link/20260909100733.1139689-15-wei.fang@oss.nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
An ENETC VF sends MAC filter changes to the PF over the VSI mailbox,
whose send path may sleep for up to 200ms waiting for completion. Since
the legacy ndo_set_rx_mode runs in atomic context, use
ndo_set_rx_mode_async instead, which runs from a workqueue under
rtnl_lock and receives pre-snapshotted unicast and multicast address
lists from the core.
Add two helpers built on the VSI mailbox:
- enetc_vf_set_mac_promisc() sends a promiscuous mode message for a
given filter type (unicast, multicast or both).
- enetc_vf_set_mac_hash_filter() sends the 64-bit MAC hash filter table,
built from the snapshotted address lists.
The callback picks the configuration from the current netdev flags:
- IFF_PROMISC: enable promiscuous mode for both unicast and multicast.
- IFF_ALLMULTI: enable multicast promiscuous mode, disable unicast
promiscuous mode and apply a unicast hash filter.
- otherwise: disable promiscuous mode and apply both unicast and
multicast hash filters.
These requests are subject to the PF-side ENETC_VF_FLAG_TRUSTED check.
For an untrusted VF (the default) the PF denies promiscuous mode and
unicast hash filtering, so only the multicast hash filter is applied,
limited to ENETC_VF_MC_HASH_BITS_MAX buckets. Mark a VF trusted via
'ip link set <pf> vf N trust on' for the full behaviour.
Set IFF_UNICAST_FLT for ENETC v4 VFs so the stack does not needlessly
fall back to full promiscuous mode; whether a unicast hash filter is
actually programmed still depends on the PF trust policy.
Since a denied request always fails, map -EOPNOTSUPP, -EACCES and -EPERM
to 0 so the core does not retry an operation that can never succeed.
ENETC v1 (LS1028A) does not support VF-to-PF MAC filter messaging and
keeps using the legacy ndev ops.
On VF removal, disable promiscuous mode and clear the MAC filters, so
that stale configuration does not persist if the VF is later bound to
another driver.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Link: https://patch.msgid.link/20260909100733.1139689-14-wei.fang@oss.nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Add VF support for the i.MX94 and i.MX95 platforms. Compared to the
LS1028A ENETC, the VF device ID is updated to 0xef00, so add it to the
VF driver's PCI device ID table. Also add the enetc4 SI ops and VF
driver data, and wire up .sriov_configure for the enetc4 PF driver so
that VFs can be created and torn down on these SoCs.
The number of VFs is not decided by the driver. It is determined by
each ENETC instance's SR-IOV hardware capability, reported through the
PCI SR-IOV TotalVFs field and configured by the SoC integration and
device tree. The driver derives it from pci_sriov_get_totalvfs() in
enetc_init_sriov_resources(); an instance that advertises zero VFs
simply cannot enable SR-IOV. So there is no driver-side revision or
device-ID check bounding the VF count.
For reference, the per-instance VF capability on these SoCs is:
- i.MX95 (v4.1): each ENETC instance supports 2 VFs.
- i.MX94 (v4.3) has two kinds of ENETC:
- standalone ENETC, the same instance type as on i.MX95, but on
i.MX94 it advertises no VFs;
- internal ENETC connected to the CPU port of the NETC switch,
which supports 3 VFs.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Link: https://patch.msgid.link/20260909100733.1139689-13-wei.fang@oss.nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
On ENETC v4, when VF performs a PCI FLR, it resets PSIPMMR[SIn_MAC_UP]
and PSIPMMR[SIn_MAC_MP] bits, which control the unicast and multicast
promiscuous mode for the corresponding SI. The reset (default) value of
these bits enables promiscuous mode, meaning that after a VF FLR, the
SI is left in promiscuous mode regardless of the configuration set by
the PF driver prior to the reset.
This is a potential security vulnerability: a malicious VM could
deliberately trigger a VF FLR to force promiscuous mode on its SI,
allowing it to capture network traffic not destined for that VF.
To mitigate this, make the following changes:
- Add ENETC_VF_FLAG_UC_PROMISC and ENETC_VF_FLAG_MC_PROMISC to
enetc_vf_flags to track the PF-managed promiscuous mode state for each
VF.
- Update enetc_msg_set_vf_mac_promisc_mode() to keep these flags in sync
whenever a VF requests a promiscuous mode change via messaging.
- Update enetc_pf_set_vf_trust() to clear both promisc flags when a VF
is untrusted, so that a subsequent FLR cannot restore promiscuous mode
that the PF has already revoked.
- Add a vf_flr_handler callback to enetc_pf_ops. The ENETC v4
implementation re-applies the tracked UC/MC promiscuous mode settings
to the hardware after each FLR, ensuring the hardware state matches
the PF-managed policy rather than the insecure reset default.
- Add enetc_vf_flr_handler() in enetc_msg.c to detect FLR events via the
PSIIDR register and dispatch to the vf_flr_handler callback. Invoke it
at the start of enetc_msg_task() before processing VF messages.
- Enable FLR interrupts in PSIIER only when a vf_flr_handler callback is
registered, keeping ENETC v1 behavior unchanged.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Reviewed-by: Claudiu Manoil <claudiu.manoil@nxp.com>
Link: https://patch.msgid.link/20260909100733.1139689-12-wei.fang@oss.nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The PSIIER register controls two categories of interrupt sources:
message-receive (MR) interrupts, which fire when a VF sends a mailbox
message to the PSI, and VF FLR interrupts, which fire when a VF
performs a Function Level Reset.
The current helpers enetc_msg_enable_mr_int() and
enetc_msg_disable_mr_int() use a read-modify-write sequence to update
only the MR bits in PSIIER, intending to preserve any other bits that
may be set. However, VF FLR interrupt support is not yet implemented,
so PSIIER only ever holds MR interrupt bits at this point. The
read-modify-write is therefore unnecessary overhead.
Simplify enetc_disable_psiier_interrupts() to write 0 directly to
PSIIER, disabling all interrupt sources at once, and simplify
enetc_enable_psiier_interrupts() to write the MR mask directly without
reading the current register value first.
Rename both helpers from the MR-specific names to names that reflect
their true scope, i.e. managing all PSIIER interrupt sources rather
than just the MR bits. This prepares the code for a future patch that
adds VF FLR interrupt support, at which point
enetc_enable_psiier_interrupts() will be extended to also set the
corresponding FLR bits.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Link: https://patch.msgid.link/20260909100733.1139689-11-wei.fang@oss.nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
ENETC v4 VF hardware supports MAC address filtering, but the underlying
resources (the PSIPMMR register and per-SI hash filter tables) are owned
by the PF. Add VSI-to-PSI mailbox messages so a VF can request MAC
filter configuration from the PF, using two new command IDs under the
existing MAC filter class (0x20):
1. ENETC_MSG_SET_MAC_HASH_TABLE (cmd_id 3): program the unicast and/or
multicast MAC hash filter table. Unicast filtering is only allowed for
a trusted VF, since it could be used to receive traffic destined for
other SIs. Multicast filtering is allowed even for an untrusted VF,
but limited to ENETC_VF_MC_HASH_BITS_MAX (8) buckets, enough for basic
operation such as IPv6 neighbor discovery and mDNS; a trusted VF may
use all 64 buckets.
2. ENETC_MSG_SET_MAC_PROMISC_MODE (cmd_id 5): enable or disable unicast/
multicast promiscuous mode, and optionally flush the hash filter
table. Enabling promiscuous mode requires a trusted VF; flushing the
table alone does not.
The PSIPMMR register is a shared resource accessed by both
enetc4_pf_set_rx_mode() and the VF message handler via a non-atomic
read-modify-write, so protect these accesses with si->gen_lock to avoid
lost updates on SMP.
When a VF loses trusted status via ndo_set_vf_trust(), clear its unicast
hash filter and disable promiscuous mode so it cannot receive traffic
beyond its allowed scope.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Link: https://patch.msgid.link/20260909100733.1139689-10-wei.fang@oss.nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The mac_filter array currently resides in struct enetc_pf and is used to
track unicast and multicast MAC address filters for the PF. Since struct
enetc_si is the common structure shared between the PF and VF drivers,
move mac_filter into struct enetc_si to prepare for MAC filter support
in the VF driver.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Link: https://patch.msgid.link/20260909100733.1139689-9-wei.fang@oss.nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Move enetc_pf_set_vf_mac() into enetc-pf-common driver as a generic
interface for both ENETC v1 and v4 PF driver to use.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Link: https://patch.msgid.link/20260909100733.1139689-7-wei.fang@oss.nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Prepare for moving enetc_pf_set_vf_mac() into the enetc-pf-common driver
by replacing enetc_pf_set_primary_mac_addr() with enetc_set_si_hw_addr().
This makes the VF primary MAC configuration path generic and allows
future enetc v4 PF driver to reuse the same interface.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Link: https://patch.msgid.link/20260909100733.1139689-6-wei.fang@oss.nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
When a VF is driven by DPDK, its user space application needs accurate
link speed information to make correct forwarding and configuration
decisions. Add link speed message support so the PF replies with the
current link speed when it receives a get-link-speed message from a VF.
Use a new message class 0x81 (ENETC_MSG_CLASS_ID_LINK_SPEED). The
PSI-to-VSI message is 16 bits: the high 8 bits are the class ID and the
low 8 bits are the speed code, so up to 255 speed values are supported
(ENETC_MSG_SPEED_MAX = 0xff). Instead of enumerating every speed above
5Gbps, use a formula so future high speeds need no enum or switch
changes:
speed_code = (link_speed - 5000) / 1000 + ENETC_MSG_SPEED_5G
The speed is read via phylink_ethtool_ksettings_get() rather than the
speed passed to the mac_link_up() callback. When the MAC has a PCS
layer, mac_link_up() reports the PCS link speed, which may differ from
the external PHY link speed; phylink_ethtool_ksettings_get() returns the
actual external link speed.
Unlike the link status message (class 0x80), the get-link-speed message
is only permitted for trusted VFs. Reading the speed requires the PF to
take rtnl_lock(), so an untrusted VF spamming this query could cause
rtnl_lock contention and starve routine network configuration on the
host. An untrusted VF therefore receives a permission-deny response; a
VF can be marked trusted via 'ip link set <pf> vf N trust on'.
Note that link speed change notification is not supported yet.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Reviewed-by: Claudiu Manoil <claudiu.manoil@nxp.com>
Link: https://patch.msgid.link/20260909100733.1139689-5-wei.fang@oss.nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Add a mechanism for VFs to learn the PF link state, using message class
0x80 (ENETC_MSG_CLASS_ID_LINK_STATUS) with three VSI-to-PSI commands:
1. ENETC_MSG_GET_CURRENT_LINK_STATUS: the VF queries the current PF link
status synchronously. This is intended for DPDK-owned VFs and is not
used by the Linux VF driver.
2. ENETC_MSG_REGISTER_LINK_CHANGE_NOTIFIER: the VF registers for link
change notification. The PF then reports the current link status and
notifies the VF on every later link change.
3. ENETC_MSG_UNREGISTER_LINK_CHANGE_NOTIFIER: the VF unregisters.
The PSI-to-VSI notification is 16 bits wide: the upper 8 bits carry the
class ID and the lower 8 bits the class code. Bit 0 of the class code
indicates the link state (1 = down, 0 = up) and bit 1 indicates whether
TX PAUSE is enabled on the PF. The TX PAUSE state is included so a VF
can decide whether to enable congestion mode on its RX BD rings, which
only works when the PF can actually send PAUSE frames.
Notifications are sent through the ENETC_PSIMSGSR register. Since sending
a notification may take a long time, as it polls the per-VF message
status bits, the actual transmission is deferred to an ordered workqueue
rather than running in the phylink link_up/link_down callbacks. The
link_status_ms_mask tracks the VFs registered for notification and is
cleared when SR-IOV is disabled.
Export enetc_pf_notify_vf_link_up() and enetc_pf_notify_vf_link_down()
for the PF phylink callbacks. Through this, VFs can perceive the link
status and report it to upper layers such as the kernel network stack,
containers and virtual machines.
Currently only the ENETC v4 driver supports this feature; v1 does not.
And the SR-IOV feature of ENETC v4 will be added by subsequent patches.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Reviewed-by: Claudiu Manoil <claudiu.manoil@nxp.com>
Link: https://patch.msgid.link/20260909100733.1139689-4-wei.fang@oss.nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The ENETC PF currently uses msg_task and msg_int_name in struct enetc_pf
to handle VSI-to-PSI mailbox messages via a workqueue and a dedicated
interrupt.
PSI-to-VSI message support will be added to the VF driver, which will
require the same mechanism: a message interrupt and a workqueue handler.
Since struct enetc_si is the common structure shared between PF and VF,
move msg_task and msg_int_name from struct enetc_pf to struct enetc_si
to allow both drivers to use them without duplication.
Also relocate the ENETC_INT_NAME_MAX macro definition ahead of struct
enetc_si so it can be used for the msg_int_name array declaration.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Reviewed-by: Claudiu Manoil <claudiu.manoil@nxp.com>
Link: https://patch.msgid.link/20260909100733.1139689-3-wei.fang@oss.nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Some mailbox messages require a higher privilege level to be executed
on behalf of the requesting VF. Introduce a trusted VF flag
(ENETC_VF_FLAG_TRUSTED) and wire up the ndo_set_vf_trust callback via
enetc_pf_set_vf_trust(), which is shared between the enetc and enetc4
PF drivers.
Trust is a PF/host-side policy bound to the VF index, decoupled from
whether SR-IOV is enabled. It may be set on a slot before SR-IOV is
enabled so a trusted VF can apply configuration right at init time,
and it is intentionally preserved across an SR-IOV disable/enable
cycle. The bounds check uses pf->total_vfs, the hardware maximum and
the size of pf->vf_state[], so pre-configuring an uninstantiated slot
is in-bounds. If a slot may be reassigned to another guest, the admin
clears trust with "ip link set <dev> vf <N> trust off".
The first message gated on trust is the VF primary MAC address change.
An untrusted VF that attempts to set its own MAC address will receive a
ENETC_MSG_CLASS_ID_PERMISSION_DENY response and the hardware will not be
programmed. This prevents a malicious VM from setting the VF address to
the MAC address of other VFs or the PF and eavesdropping on the traffic
of other SIs, and it stops a malicious VM from arbitrarily changing the
VF MAC address to achieve MAC address spoofing and bypass security
policies. This does not regress VF bring-up. The PF programs a valid
primary MAC into every VF slot at probe, and the VF loads it from its
own SIPMAR0/1 registers.
Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Link: https://patch.msgid.link/20260909100733.1139689-2-wei.fang@oss.nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Handle errors from platform_get_irq_byname_optional() explicitly while
preserving the existing fallback to platform_get_irq() when the named IRQ
is not available.
Propagate errors other than -ENXIO from the optional IRQ lookup instead
of silently falling back to the indexed IRQ lookup.
In particular, silently ignoring -EPROBE_DEFER can cause the driver to
continue probing instead of deferring as required.
Reviewed-by: Wei Fang <wei.fang@nxp.com>
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Link: https://patch.msgid.link/20260911040021.12289-2-phucduc.bui@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
