Cross-merge networking fixes after downstream PR (net-6.17-rc8).
Conflicts:
tools/testing/selftests/drivers/net/bonding/Makefile 87951b566446 selftests: bonding: add test for passive LACP mode c2377f1763e9 selftests: bonding: add test for LACP actor port priority
Adjacent changes:
drivers/net/ethernet/cadence/macb.h fca3dc859b20 net: macb: remove illusion about TBQPH/RBQPH being per-queue 89934dbf169e net: macb: Add TAPRIO traffic scheduling support
drivers/net/ethernet/cadence/macb_main.c fca3dc859b20 net: macb: remove illusion about TBQPH/RBQPH being per-queue 89934dbf169e net: macb: Add TAPRIO traffic scheduling support
====================
net: stmmac: Add support for Allwinner A523 GMAC200
This is v8 of my Allwinner A523 GMAC200 support series. This is based on
next-20250925.
This version only contains the DT binding and driver patches. The device
tree patches are basically the same as the previous version.
This series adds support for the second Ethernet controller found on the
Allwinner A523 SoC family. This controller, dubbed GMAC200, is a DWMAC4
core with an integration layer around it. The integration layer is
similar to older Allwinner generations, but with an extra memory bus
gate and separate power domain.
Patch 1 adds a new compatible string combo to the existing Allwinner
EMAC binding.
Patch 2 adds a new driver for this core and integration combo.
====================
net: stmmac: Add support for Allwinner A523 GMAC200
The Allwinner A523 SoC family has a second Ethernet controller, called
the GMAC200 in the BSP and T527 datasheet, and referred to as GMAC1 for
numbering. This controller, according to BSP sources, is fully
compatible with a slightly newer version of the Synopsys DWMAC core.
The glue layer around the controller is the same as found around older
DWMAC cores on Allwinner SoCs. The only slight difference is that since
this is the second controller on the SoC, the register for the clock
delay controls is at a different offset. Last, the integration includes
a dedicated clock gate for the memory bus and the whole thing is put in
a separately controllable power domain.
Add a new driver for this hardware supporting the integration layer.
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Chen-Yu Tsai <wens@csie.org> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/20250925191600.3306595-3-wens@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The Allwinner A523 SoC family has a second Ethernet controller, called
the GMAC200 in the BSP and T527 datasheet, and referred to as GMAC1 for
numbering. This controller, according to BSP sources, is fully
compatible with a slightly newer version of the Synopsys DWMAC core.
The glue layer around the controller is the same as found around older
DWMAC cores on Allwinner SoCs. The only slight difference is that since
this is the second controller on the SoC, the register for the clock
delay controls is at a different offset. Last, the integration includes
a dedicated clock gate for the memory bus and the whole thing is put in
a separately controllable power domain.
Add a compatible string entry for it, and work in the requirements for
a second clock and a power domain.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Chen-Yu Tsai <wens@csie.org> Link: https://patch.msgid.link/20250925191600.3306595-2-wens@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
====================
octeontx2: fix bitmap leaks in PF and VF
Two small patches that free the AF_XDP bitmap in the PF and VF
remove paths. Both carry the same Fixes tag and should go to
stable.
====================
Bo Sun [Tue, 30 Sep 2025 06:12:36 +0000 (14:12 +0800)]
octeontx2-pf: fix bitmap leak
The bitmap allocated with bitmap_zalloc() in otx2_probe() was not
released in otx2_remove(). Unbinding and rebinding the driver therefore
triggers a kmemleak warning:
Call bitmap_free() in the remove path to fix the leak.
Fixes: efabce290151 ("octeontx2-pf: AF_XDP zero copy receive support") Signed-off-by: Bo Sun <bo@mboxify.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Bo Sun [Tue, 30 Sep 2025 06:12:35 +0000 (14:12 +0800)]
octeontx2-vf: fix bitmap leak
The bitmap allocated with bitmap_zalloc() in otx2vf_probe() was not
released in otx2vf_remove(). Unbinding and rebinding the driver therefore
triggers a kmemleak warning:
Call bitmap_free() in the remove path to fix the leak.
Fixes: efabce290151 ("octeontx2-pf: AF_XDP zero copy receive support") Signed-off-by: Bo Sun <bo@mboxify.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Gal Pressman [Sun, 28 Sep 2025 21:25:23 +0000 (00:25 +0300)]
net/mlx5e: Use extack in set rxfh callback
The ->set/create/modify_rxfh() callbacks now pass a valid extack instead
of NULL through netlink [1]. In case of an error, reflect it through
extack instead of a dmesg print.
Introduce a dedicated structure to group RSS initialization parameters
that are only used during RSS creation, and drop the "init" prefix
from pkt_merge_param.
Jianbo Liu [Sun, 28 Sep 2025 21:25:18 +0000 (00:25 +0300)]
net/mlx5e: Prevent entering switchdev mode with inconsistent netns
When a PF enters switchdev mode, its netdevice becomes the uplink
representor but remains in its current network namespace. All other
representors (VFs, SFs) are created in the netns of the devlink
instance.
If the PF's netns has been moved and differs from the devlink's netns,
enabling switchdev mode would create a state where the OVS control
plane (ovs-vsctl) cannot manage the switch because the PF uplink
representor and the other representors are split across different
namespaces.
To prevent this inconsistent configuration, block the request to enter
switchdev mode if the PF netdevice's netns does not match the netns of
its devlink instance.
As part of this change, the PF's netns is first marked as immutable.
This prevents race conditions where the netns could be changed after
the check is performed but before the mode transition is complete, and
it aligns the PF's behavior with that of the final uplink representor.
The existing solution of complex matchers splits the match parameters
across two, and exactly two, matchers. For some rather extreme cases
(e.g. IPv6-in-IPv6 tunnels), even two matchers are not enough.
Generalize complex matchers to up to 4 submatchers, and allow easy
extension to more if needed. This resulted in rewriting a large part
of the high-level complex matchers logic, but the original concepts
were rock solid and still hold.
Key characteristics of the new implementation:
* Rework complex matchers to include multiple submatchers. All
submatchers but the first are isolated, in keeping with the existing
paradigm of handing off to specialized matchers that are not otherwise
reachable by regular rules.
* Similarly, rework complex rules to allow splitting them into more than
two simple rules. Rules continue to be refcounted to allow for
multiple complex rules matching on identical parts of the match
params.
* Rely on the match tag, as opposed to the entire match_param, to hash
subrules. This results in lower memory usage.
* Prefer to split the original user-supplied match parameters rather
than the internal field descriptors. This avoids the awkward
transition back and forth between the two formats.
* Allow splitting multi-dword fields across matchers. The only
restrictions that the new implementation impose are: a) any fragment
of an IP address must be accompanied by a match on the IP version; and
b) a single lower dword of an IPv6 address cannot be present in a
submatcher as it would be interpreted as an IPv4 address.
* Employ a greedy algorithm to split the match params, as opposed to
complete search. The results are not optimal, but the algorithm is now
linear compared to exponential. Consequently, we see complex matcher
creation time drops two orders of magnitude in our tests.
net/mlx5: Improve write-combining test reliability for ARM64 Grace CPUs
Write combining is an optimization feature in CPUs that is frequently
used by modern devices to generate 32 or 64 byte TLPs at the PCIe level.
These large TLPs allow certain optimizations in the driver to HW
communication that improve performance. As WC is unpredictable and
optional the HW designs all tolerate cases where combining doesn't
happen and simply experience a performance degradation.
Unfortunately many virtualization environments on all architectures have
done things that completely disable WC inside the VM with no generic way
to detect this. For example WC was fully blocked in ARM64 KVM until
commit 8c47ce3e1d2c ("KVM: arm64: Set io memory s2 pte as normalnc for
vfio pci device").
Trying to use WC when it is known not to work has a measurable
performance cost (~5%). Long ago mlx5 developed an boot time algorithm
to test if WC is available or not by using unique mlx5 HW features to
measure how many large TLPs the device is receiving. The SW generates a
large number of combining opportunities and if any succeed then WC is
declared working.
In mlx5 the WC optimization feature is never used by the kernel except
for the boot time test. The WC is only used by userspace in rdma-core.
Sadly modern ARM CPUs, especially NVIDIA Grace, have a combining
implementation that is very unreliable compared to pretty much
everything prior. This is being fixed architecturally in new CPUs with a
new ST64B instruction, but current shipping devices suffer this problem.
Unreliable means the SW can present thousands of combining opportunities
and the HW will not combine for any of them, which creates a performance
degradation, and critically fails the mlx5 boot test. However, the CPU
is very sensitive to the instruction sequence used, with the better
options being sufficiently good that the performance loss from the
unreliable CPU is not measurable.
Broadly there are several options, from worst to best:
1) A C loop doing a u64 memcpy.
This was used prior to commit ef302283ddfc
("IB/mlx5: Use __iowrite64_copy() for write combining stores")
and failed almost all the time on Grace CPUs.
2) ARM64 assembly with consecutive 8 byte stores. This was implemented
as an arch-generic __iowriteXX_copy() family of functions suitable
for performance use in drivers for WC. commit ead79118dae6
("arm64/io: Provide a WC friendly __iowriteXX_copy()") provided the
ARM implementation.
3) ARM64 assembly with consecutive 16 byte stores. This was rejected
from kernel use over fears of virtualization failures. Common ARM
VMMs will crash if STP is used against emulated memory.
4) A single NEON store instruction. Userspace has used this option for a
very long time, it performs well.
5) For future silicon the new ST64B instruction is guaranteed to
generate a 64 byte TLP 100% of the time
The past upgrade from #1 to #2 was thought to be sufficient to solve
this problem. However, more testing on more systems shows that #3 is
still problematic at a low frequency and the kernel test fails.
Thus, make the mlx5 use the same instructions as userspace during the
boot time WC self test. This way the WC test matches the userspace and
will properly detect the ability of HW to support the WC workload that
userspace will generate. While #4 still has imperfect combining
performance, it is substantially better than #2, and does actually give
a performance win to applications. Self-test failures with #2 are like
3/10 boots, on some systems, #4 has never seen a boot failure.
There is no real general use case for a NEON based WC flow in the
kernel. This is not suitable for any performance path work as getting
into/out of a NEON context is fairly expensive compared to the gain of
WC. Future CPUs are going to fix this issue by using an new ARM
instruction and __iowriteXX_copy() will be updated to use that
automatically, probably using the ALTERNATES mechanism.
Since this problem is constrained to mlx5's unique situation of needing
a non-performance code path to duplicate what mlx5 userspace is doing as
a matter of self-testing, implement it as a one line inline assembly in
the driver directly.
Lastly, this was concluded from the discussion with ARM maintainers
which confirms that this is the best approach for the solution:
https://lore.kernel.org/r/aHqN_hpJl84T1Usi@arm.com
Commit in question breaks the mapping of PGs to pools for some SKUs.
Specifically multi-host NICs seem to be shipped with a custom buffer
configuration which maps the lossy PG to pool 4. But the bad commit
overrides this with pool 0 which does not have sufficient buffer space
reserved. Resulting in ~40% packet loss. The commit also breaks BMC /
OOB connection completely (100% packet loss).
Revert, similarly to commit 3fbfe251cc9f ("Revert "net/mlx5e: Update and
set Xon/Xoff upon port speed set""). The breakage is exactly the same,
the only difference is that quoted commit would break the NIC immediately
on boot, and the currently reverted commit only when MTU is changed.
Note: "good" kernels do not restore the configuration, so downgrade isn't
enough to recover machines. A NIC power cycle seems to be necessary to
return to a healthy state (or overriding the relevant registers using
a custom patch).
Fixes: ceddedc969f0 ("net/mlx5e: Update and set Xon/Xoff upon MTU set") Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20250929181529.1848157-1-kuba@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Platforms with many cpus and relatively slow inter connect show
a significant spinlock contention in skb_attempt_defer_free().
This series refactors this infrastructure to be NUMA aware,
and lockless.
Tested on various platforms, including AMD Zen 2/3/4
and Intel Granite Rapids, showing significant cost reductions
under network stress (more than 20 Mpps).
====================
Eric Dumazet [Sun, 28 Sep 2025 08:49:33 +0000 (08:49 +0000)]
net: use llist for sd->defer_list
Get rid of sd->defer_lock and adopt llist operations.
We optimize skb_attempt_defer_free() for the common case,
where the packet is queued. Otherwise sd->defer_count
is increasing, until skb_defer_free_flush() clears it.
====================
psp: add a kselftest suite and netdevsim implementation
Add a basic test suite for drivers that support PSP. Also, add a PSP
implementation in the netdevsim driver.
The netdevsim implementation does encapsulation and decapsulation of
PSP packets, but no crypto.
The tests cover the basic usage of the uapi, and demonstrate key
exchange and connection setup. The tests and netdevsim support IPv4
and IPv6. Here is an example run on a system with a CX7 NIC.
TAP version 13
1..28
ok 1 psp.data_basic_send_v0_ip4
ok 2 psp.data_basic_send_v0_ip6
ok 3 psp.data_basic_send_v1_ip4
ok 4 psp.data_basic_send_v1_ip6
ok 5 psp.data_basic_send_v2_ip4 # SKIP ('PSP version not supported', 'hdr0-aes-gmac-128')
ok 6 psp.data_basic_send_v2_ip6 # SKIP ('PSP version not supported', 'hdr0-aes-gmac-128')
ok 7 psp.data_basic_send_v3_ip4 # SKIP ('PSP version not supported', 'hdr0-aes-gmac-256')
ok 8 psp.data_basic_send_v3_ip6 # SKIP ('PSP version not supported', 'hdr0-aes-gmac-256')
ok 9 psp.data_mss_adjust_ip4
ok 10 psp.data_mss_adjust_ip6
ok 11 psp.dev_list_devices
ok 12 psp.dev_get_device
ok 13 psp.dev_get_device_bad
ok 14 psp.dev_rotate
ok 15 psp.dev_rotate_spi
ok 16 psp.assoc_basic
ok 17 psp.assoc_bad_dev
ok 18 psp.assoc_sk_only_conn
ok 19 psp.assoc_sk_only_mismatch
ok 20 psp.assoc_sk_only_mismatch_tx
ok 21 psp.assoc_sk_only_unconn
ok 22 psp.assoc_version_mismatch
ok 23 psp.assoc_twice
ok 24 psp.data_send_bad_key
ok 25 psp.data_send_disconnect
ok 26 psp.data_stale_key
ok 27 psp.removal_device_rx # XFAIL Test only works on netdevsim
ok 28 psp.removal_device_bi # XFAIL Test only works on netdevsim
# Totals: pass:22 fail:0 xfail:2 xpass:0 skip:4 error:0
#
# Responder logs (0):
# STDERR:
# Set PSP enable on device 1 to 0x3
# Set PSP enable on device 1 to 0x0
Jakub Kicinski [Sat, 27 Sep 2025 22:54:20 +0000 (15:54 -0700)]
selftests: drv-net: psp: add tests for destroying devices
Add tests for making sure device can disappear while associations
exist. This is netdevsim-only since destroying real devices is
more tricky.
Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> Link: https://patch.msgid.link/20250927225420.1443468-9-kuba@kernel.org Reviewed-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Jakub Kicinski [Sat, 27 Sep 2025 22:54:19 +0000 (15:54 -0700)]
selftests: drv-net: psp: add test for auto-adjusting TCP MSS
Test TCP MSS getting auto-adjusted. PSP adds an encapsulation overhead
of 40B per packet, when used in transport mode without any
virtualization cookie or other optional PSP header fields. The kernel
should adjust the MSS for a connection after PSP tx state is reached.
Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> Link: https://patch.msgid.link/20250927225420.1443468-8-kuba@kernel.org Reviewed-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Add test checking conditions which lead to connections breaking.
Using bad key or connection gets stuck if device key is rotated
twice.
Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> Link: https://patch.msgid.link/20250927225420.1443468-7-kuba@kernel.org Reviewed-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Jakub Kicinski [Sat, 27 Sep 2025 22:54:17 +0000 (15:54 -0700)]
selftests: drv-net: psp: add association tests
Add tests for exercising PSP associations for TCP sockets.
Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> Link: https://patch.msgid.link/20250927225420.1443468-6-kuba@kernel.org Reviewed-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Jakub Kicinski [Sat, 27 Sep 2025 22:54:16 +0000 (15:54 -0700)]
selftests: drv-net: psp: add basic data transfer and key rotation tests
Add basic tests for sending data over PSP and making sure that key
rotation toggles the MSB of the spi.
Deploy PSP responder on the remote end. We also need a healthy dose
of common helpers for setting up the connections, assertions and
interrogating socket state on the Python side.
Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> Link: https://patch.msgid.link/20250927225420.1443468-5-kuba@kernel.org Reviewed-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Jakub Kicinski [Sat, 27 Sep 2025 22:54:15 +0000 (15:54 -0700)]
selftests: drv-net: add PSP responder
PSP tests need the remote system to support PSP, and some PSP capable
application to exchange data with. Create a simple PSP responder app
which we can build and deploy to the remote host. The tests themselves
can be written in Python but for ease of deploying the responder is in C
(using C YNL).
Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> Link: https://patch.msgid.link/20250927225420.1443468-4-kuba@kernel.org Reviewed-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Jakub Kicinski [Sat, 27 Sep 2025 22:54:14 +0000 (15:54 -0700)]
selftests: drv-net: base device access API test
Simple PSP test to getting info about PSP devices.
Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> Link: https://patch.msgid.link/20250927225420.1443468-3-kuba@kernel.org Reviewed-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Jakub Kicinski [Sat, 27 Sep 2025 22:54:13 +0000 (15:54 -0700)]
netdevsim: a basic test PSP implementation
Provide a PSP implementation for netdevsim.
Use psp_dev_encapsulate() and psp_dev_rcv() to do actual encapsulation
and decapsulation on skbs, but perform no encryption or decryption. In
order to make encryption with a bad key result in a drop on the peer's
rx side, we stash our psd's generation number in the first byte of each
key before handing to the peer.
Signed-off-by: Jakub Kicinski <kuba@kernel.org> Co-developed-by: Daniel Zahka <daniel.zahka@gmail.com> Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> Link: https://patch.msgid.link/20250927225420.1443468-2-kuba@kernel.org Reviewed-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The poll interval is a fixed value, so we don't need a static variable
for it. The change also allows to use standard macro
module_platform_driver, avoiding some boilerplate code.
page_pool_init() returns E2BIG when the page_pool size goes above 32K
pages. As some drivers are configuring the page_pool size according to
the MTU and ring size, there are cases where this limit is exceeded and
the queue creation fails.
The page_pool size doesn't have to cover a full queue, especially for
larger ring size. So clamp the size instead of returning an error. Do
this in the core to avoid having each driver do the clamping.
The current limit was deemed to high [1] so it was reduced to 16K to avoid
page waste.
tipc: adjust tipc_nodeid2string() to return string length
Since the value returned by 'tipc_nodeid2string()' is not used, the
function may be adjusted to return the length of the result, which
is helpful to drop a few calls to 'strlen()' in 'tipc_link_create()'
and 'tipc_link_bc_create()'. Compile tested only.
net: enetc: initialize SW PIR and CIR based HW PIR and CIR values
Software can only initialize the PIR and CIR of the command BD ring after
a FLR, and these two registers can only be set to 0. But the reset values
of these two registers are 0, so software does not need to update them.
If there is no a FLR and PIR and CIR are not 0, resetting them to 0 or
other values by software will cause the command BD ring to work
abnormally. This is because of an internal context in the ring prefetch
logic that will retain the state from the first incarnation of the ring
and continue prefetching from the stale location when the ring is
reinitialized. The internal context can only be reset by the FLR.
In addition, there is a logic error in the implementation, next_to_clean
indicates the software CIR and next_to_use indicates the software PIR.
But the current driver uses next_to_clean to set PIR and use next_to_use
to set CIR. This does not cause a problem in actual use, because the
current command BD ring is only initialized after FLR, and the initial
values of next_to_use and next_to_clean are both 0.
Therefore, this patch removes the initialization of PIR and CIR. Instead,
next_to_use and next_to_clean are initialized by reading the values of
PIR and CIR.
net: nfc: nci: Add parameter validation for packet data
Syzbot reported an uninitialized value bug in nci_init_req, which was
introduced by commit 5aca7966d2a7 ("Merge tag
'perf-tools-fixes-for-v6.17-2025-09-16' of
git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools").
This bug arises due to very limited and poor input validation
that was done at nic_valid_size(). This validation only
validates the skb->len (directly reflects size provided at the
userspace interface) with the length provided in the buffer
itself (interpreted as NCI_HEADER). This leads to the processing
of memory content at the address assuming the correct layout
per what opcode requires there. This leads to the accesses to
buffer of `skb_buff->data` which is not assigned anything yet.
Following the same silent drop of packets of invalid sizes at
`nic_valid_size()`, add validation of the data in the respective
handlers and return error values in case of failure. Release
the skb if error values are returned from handlers in
`nci_nft_packet` and effectively do a silent drop
Possible TODO: because we silently drop the packets, the
call to `nci_request` will be waiting for completion of request
and will face timeouts. These timeouts can get excessively logged
in the dmesg. A proper handling of them may require to export
`nci_request_cancel` (or propagate error handling from the
nft packets handlers).
Qingfang Deng [Thu, 25 Sep 2025 05:10:59 +0000 (13:10 +0800)]
6pack: drop redundant locking and refcounting
The TTY layer already serializes line discipline operations with
tty->ldisc_sem, so the extra disc_data_lock and refcnt in 6pack
are unnecessary.
Removing them simplifies the code and also resolves a lockdep warning
reported by syzbot. The warning did not indicate a real deadlock, since
the write-side lock was only taken in process context with hardirqs
disabled.
Reported-by: syzbot+5fd749c74105b0e1b302@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/68c858b0.050a0220.3c6139.0d1c.GAE@google.com/ Signed-off-by: Qingfang Deng <dqfext@gmail.com> Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://patch.msgid.link/20250925051059.26876-1-dqfext@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Hangbin Liu [Thu, 25 Sep 2025 02:33:04 +0000 (02:33 +0000)]
selftests: bonding: add ipsec offload test
This introduces a test for IPSec offload over bonding, utilizing netdevsim
for the testing process, as veth interfaces do not support IPSec offload.
The test will ensure that the IPSec offload functionality remains operational
even after a failover event occurs in the bonding configuration.
Here is the test result:
TEST: bond_ipsec_offload (active_slave eth0) [ OK ]
TEST: bond_ipsec_offload (active_slave eth1) [ OK ]
Hangbin Liu [Thu, 25 Sep 2025 02:33:03 +0000 (02:33 +0000)]
bonding: fix xfrm offload feature setup on active-backup mode
The active-backup bonding mode supports XFRM ESP offload. However, when
a bond is added using command like `ip link add bond0 type bond mode 1
miimon 100`, the `ethtool -k` command shows that the XFRM ESP offload is
disabled. This occurs because, in bond_newlink(), we change bond link
first and register bond device later. So the XFRM feature update in
bond_option_mode_set() is not called as the bond device is not yet
registered, leading to the offload feature not being set successfully.
To resolve this issue, we can modify the code order in bond_newlink() to
ensure that the bond device is registered first before changing the bond
link parameters. This change will allow the XFRM ESP offload feature to be
correctly enabled.
Documentation: net: add flow control guide and document ethtool API
Introduce a new document, flow_control.rst, to provide a comprehensive
guide on Ethernet Flow Control in Linux. The guide explains how flow
control works, how autonegotiation resolves pause capabilities, and how
to configure it using ethtool and Netlink.
In parallel, document the pause and pause-stat attributes in the
ethtool.yaml netlink spec. This enables the ynl tool to generate
kernel-doc comments for the corresponding enums in the UAPI header,
making the C interface self-documenting.
Finally, replace the legacy flow control section in phy.rst with a
reference to the new document and add pointers in the relevant C source
files.
For some hardware, the phase shift may result from averaging previous values
and the newly measured value. In this case, the averaging is controlled by
a configurable averaging factor.
Add new device level attribute phase-offset-avg-factor, appropriate
callbacks and implement them in zl3073x driver.
====================
Ivan Vecera [Sat, 27 Sep 2025 08:49:12 +0000 (10:49 +0200)]
dpll: zl3073x: Allow to configure phase offset averaging factor
The DPLL phase measurement block uses an exponential moving average with
a configurable averaging factor. Measurements are taken at approximately
40 Hz or at the reference frequency, whichever is lower.
Currently, factor=2 is used to prioritize fast response for dynamic
phase changes. For applications needing a stable, precise average phase
offset where rapid changes are unlikely, a higher factor is recommended.
Implement the .phase_offset_avg_factor_get/set callbacks to allow a user
to adjust this factor.
Add new callback operations for a dpll device:
- phase_offset_avg_factor_get(...) - to obtain current phase offset
averaging factor from dpll device,
- phase_offset_avg_factor_set(...) - to set phase offset averaging factor
Obtain the factor value using the get callback and provide it to the user
if the device driver implement this callback. Execute the set callback upon
user requests, if the driver implement it.
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
v2:
* do not require 'set' callback to retrieve current value
* always call 'set' callback regardless of current value Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Link: https://patch.msgid.link/20250927084912.2343597-3-ivecera@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Ivan Vecera [Sat, 27 Sep 2025 08:49:10 +0000 (10:49 +0200)]
dpll: add phase-offset-avg-factor device attribute to netlink spec
Add dpll device level attribute DPLL_A_PHASE_OFFSET_AVG_FACTOR to allow
control over a calculation of reported phase offset value. Attribute is
present, if the driver provides such capability, otherwise attribute
shall not be present.
Add sync reset timeout to stop poll_sync_reset in case there was no
reset done or abort event within timeout. Otherwise poll sync reset will
just continue and in case of fw fatal error no health reporting will be
done.
net/mlx5: pagealloc: Fix reclaim race during command interface teardown
The reclaim_pages_cmd() function sends a command to the firmware to
reclaim pages if the command interface is active.
A race condition can occur if the command interface goes down (e.g., due
to a PCI error) while the mlx5_cmd_do() call is in flight. In this
case, mlx5_cmd_do() will return an error. The original code would
propagate this error immediately, bypassing the software-based page
reclamation logic that is supposed to run when the command interface is
down.
Fix this by checking whether mlx5_cmd_do() returns -ENXIO, which mark
that command interface is down. If this is the case, fall through to
the software reclamation path. If the command failed for any another
reason, or finished successfully, return as before.
Fixes: b898ce7bccf1 ("net/mlx5: cmdif, Avoid skipping reclaim pages if FW is not accessible") Signed-off-by: Shay Drory <shayd@nvidia.com> Reviewed-by: Moshe Shemesh <moshe@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net/mlx5: Stop polling for command response if interface goes down
Stop polling on firmware response to command in polling mode if the
command interface got down. This situation can occur, for example, if a
firmware fatal error is detected during polling.
This change halts the polling process when the command interface goes
down, preventing unnecessary waits.
Fixes: b898ce7bccf1 ("net/mlx5: cmdif, Avoid skipping reclaim pages if FW is not accessible") Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Reviewed-by: Shay Drori <shayd@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jakub Kicinski [Tue, 30 Sep 2025 01:49:58 +0000 (18:49 -0700)]
Merge tag 'mlx5-next-lag' of git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux
Tariq Toukan says:
====================
mlx5-next updates 2025-09-28
* tag 'mlx5-next-lag' of git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux:
net/mlx5: IFC add balance ID and LAG per MP group bits
net/mlx5: Add IFC bit for TIR/SQ order capability
====================
The driver did not handle failure of `netdev_alloc_skb_ip_align()`.
If the allocation failed, dereferencing `skb->protocol` could lead to
a NULL pointer dereference.
This patch tries to allocate `skb`. If the allocation fails, it falls
back to the normal path.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Suggested-by: Jakub Kicinski <kuba@kernel.org>
Tested-on: D-Link DGE-550T Rev-A3 Signed-off-by: Yeounsu Moon <yyyynoom@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250928190124.1156-1-yyyynoom@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
====================
selftest: packetdrill: Import TFO server tests.
The series imports 15 TFO server tests from google/packetdrill and
adds 2 more tests.
The repository has two versions of tests for most scenarios; one uses
the non-experimental option (34), and the other uses the experimental
option (255) with 0xF989.
Basically, we only import the non-experimental version of tests, and
for the experimental option, tcp_fastopen_server_experimental_option.pkt
is added.
The former is completely covered by icmp-before-accept.pkt.
The later's delta is the src/dst IP pair to generate a different
cookie, but supporting dualstack requires churn in ksft_runner.sh,
so defered to future series. Also, sockopt-fastopen-key.pkt covers
the same function.
The following tests have the experimental version only, so converted
to the non-experimental option:
For the imported tests, these common changes are applied.
* Add SPDX header
* Adjust path to default.sh
* Adjust sysctl w/ set_sysctls.py
* Use TFO_COOKIE instead of a raw hex value
* Use SOCK_NONBLOCK for socket() not to block accept()
* Add assertions for TCP state if commented
* Remove unnecessary delay (e.g. +0.1 setsockopt(SO_REUSEADDR), etc)
With this series, except for simple{1,2,3}.pkt, we can remove TFO server
tests in google/packetdrill.
====================
sockopt-fastopen-key.pkt does not have the non-experimental
version, so the Experimental version is converted, FOEXP -> FO.
The test sets net.ipv4.tcp_fastopen_key=0-0-0-0 and instead
sets another key via setsockopt(TCP_FASTOPEN_KEY).
The first listener generates a valid cookie in response to TFO
option without cookie, and the second listner creates a TFO socket
using the valid cookie.
TCP_FASTOPEN_KEY is adjusted to use the common key in default.sh
so that we can use TFO_COOKIE and support dualstack. Similarly,
TFO_COOKIE_ZERO for the 0-0-0-0 key is defined.
This imports the non-experimental version of opt34/reset-*.pkt.
| Child | RST | sk_err |
---------------------------------+---------+-------------------------------+---------+
reset-after-accept.pkt | TFO | after accept(), SYN_RECV | read() |
reset-close-with-unread-data.pkt | TFO | after accept(), SYN_RECV | write() |
reset-before-accept.pkt | TFO | before accept(), SYN_RECV | read() |
reset-non-tfo-socket.pkt | non-TFO | before accept(), ESTABLISHED | write() |
The first 3 files test scenarios where a SYN_RECV socket receives RST
before/after accept() and data in SYN must be read() without error,
but the following read() or fist write() will return ECONNRESET.
This imports the non-experimental version of icmp-before-accept.pkt.
This file tests the scenario where an ICMP unreachable packet for a
not-yet-accept()ed socket changes its state to TCP_CLOSE, but the
SYN data must be read without error, and the following read() returns
EHOSTUNREACH.
Note that this test support only IPv4 as icmp is used.
selftest: packetdrill: Import TFO server basic tests.
This imports basic TFO server tests from google/packetdrill.
The repository has two versions of tests for most scenarios; one uses
the non-experimental option (34), and the other uses the experimental
option (255) with 0xF989.
This only imports the following tests of the non-experimental version
placed in [0]. I will add a specific test for the experimental option
handling later.
The original pure-syn-data.pkt missed setsockopt(TCP_FASTOPEN) and did
not test TFO server in some scenarios unintentionally, so setsockopt()
is added where needed. In addition, non-TFO scenario is stripped as
it is covered by basic-non-tfo-listener.pkt. Also, I added basic- prefix.
selftest: packetdrill: Define common TCP Fast Open cookie.
TCP Fast Open cookie is generated in __tcp_fastopen_cookie_gen_cipher().
The cookie value is generated from src/dst IPs and a key configured by
setsockopt(TCP_FASTOPEN_KEY) or net.ipv4.tcp_fastopen_key.
The default.sh sets net.ipv4.tcp_fastopen_key, and the original packetdrill
defines the corresponding cookie as TFO_COOKIE in run_all.py. [0]
Then, each test does not need to care about the value, and we can easily
update TFO_COOKIE in case __tcp_fastopen_cookie_gen_cipher() changes the
algorithm.
However, some tests use the bare hex value for specific IPv4 addresses
and do not support IPv6.
Let's define the same TFO_COOKIE in ksft_runner.sh.
We will replace such bare hex values with TFO_COOKIE except for a single
test for setsockopt(TCP_FASTOPEN_KEY).
selftest: packetdrill: Set ktap_set_plan properly for single protocol test.
The cited commit forgot to update the ktap_set_plan call.
ktap_set_plan sets the number of tests (KSFT_NUM_TESTS), which must
match the number of executed tests (KTAP_CNT_PASS + KTAP_CNT_SKIP +
KTAP_CNT_XFAIL) in ktap_finished.
Otherwise, the selftest exit()s with 1.
Let's adjust KSFT_NUM_TESTS based on supported protocols.
While at it, misalignment is fixed up.
Fixes: a5c10aa3d1ba ("selftests/net: packetdrill: Support single protocol test.") Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20250927213022.1850048-2-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net: ena: return 0 in ena_get_rxfh_key_size() when RSS hash key is not configurable
In EC2 instances where the RSS hash key is not configurable, ethtool
shows bogus RSS hash key since ena_get_rxfh_key_size() unconditionally
returns ENA_HASH_KEY_SIZE.
Commit 6a4f7dc82d1e ("net: ena: rss: do not allocate key when not
supported") added proper handling for devices that don't support RSS
hash key configuration, but ena_get_rxfh_key_size() has been unchanged.
When the RSS hash key is not configurable, return 0 instead of
ENA_HASH_KEY_SIZE to clarify getting the value is not supported.
Tested on m5 instance families.
Without patch:
# ethtool -x ens5 | grep -A 1 "RSS hash key"
RSS hash key:
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
With patch:
# ethtool -x ens5 | grep -A 1 "RSS hash key"
RSS hash key:
Operation not supported
nfp: fix RSS hash key size when RSS is not supported
The nfp_net_get_rxfh_key_size() function returns -EOPNOTSUPP when
devices don't support RSS, and callers treat the negative value as a
large positive value since the return type is u32.
Return 0 when devices don't support RSS, aligning with the ethtool
interface .get_rxfh_key_size() that requires returning 0 in such cases.
This was a benefit for UDP flood case, which was later greatly improved
with commits 6471658dc66c ("udp: use skb_attempt_defer_free()")
and b650bf0977d3 ("udp: remove busylock and add per NUMA queues").
Apparently blamed commit added a regression for RAW sockets, possibly
because they do not use the dual RX queue strategy that UDP has.
sock_queue_rcv_skb_reason() and RAW recvmsg() compete for sk_receive_buf
and sk_rmem_alloc changes, and them being in the same
cache line reduce performance.
Fixes: 4effb335b5da ("net: group sk_backlog and sk_receive_queue") Reported-by: kernel test robot <oliver.sang@intel.com> Closes: https://lore.kernel.org/oe-lkp/202509281326.f605b4eb-lkp@intel.com Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Willem de Bruijn <willemb@google.com> Cc: David Ahern <dsahern@kernel.org> Cc: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20250929182112.824154-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net: stmmac: Convert open-coded register polling to helper macro
Drop the open-coded register polling routines.
Use readl_poll_timeout_atomic() in atomic state.
Also adjust the delay time to 10us which seems more reasonable.
Tested on NXP i.MX8MP and ROCKCHIP RK3588 boards,
the break condition was met right after the first polling,
no delay involved at all.
So the 10us delay should be long enough for most cases.
This series includes several changes to the MPTCP RX path. The main
goals are improving the RX performances, and increase the long term
maintainability.
Some changes reflects recent(ish) improvements introduced in the TCP
stack: patch 1, 2 and 3 are the MPTCP counter part of SKB deferral free
and auto-tuning improvements. Note that patch 3 could possibly fix
additional issues, and overall such patch should protect from similar
issues to arise in the future.
Patches 4-7 are aimed at introducing the socket backlog usage which will
be done in a later series to process the packets received by the
different subflows while the msk socket is owned.
Patch 8 is not related to the RX path, but it contains additional tests
for new features recently introduced in net-next.
====================
Here are a few sub-tests for mptcp_join.sh, validating the new 'laminar'
endpoint type.
In a setup where subflows created using the routing rules would be
rejected by the listener, and where the latter announces one IP address,
some cases are verified:
- Without any 'laminar' endpoints: no new subflows are created.
- With one 'laminar' endpoint: a second subflow is created.
- With multiple 'laminar' endpoints: 2 IPv4 subflows are created.
- With one 'laminar' endpoint, but the server announcing a second IP
address, only one subflow is created.
- With one 'laminar' + 'subflow' endpoint, the same endpoint is only
used once.
Paolo Abeni [Sat, 27 Sep 2025 09:40:43 +0000 (11:40 +0200)]
mptcp: minor move_skbs_to_msk() cleanup
Such function is called only by __mptcp_data_ready(), which in turn
is always invoked when msk is not owned by the user: we can drop the
redundant, related check.
Additionally mptcp needs to propagate the socket error only for
current subflow.
Paolo Abeni [Sat, 27 Sep 2025 09:40:41 +0000 (11:40 +0200)]
mptcp: remove unneeded mptcp_move_skb()
Since commit b7535cfed223 ("mptcp: drop legacy code around RX EOF"),
sk_shutdown can't change during the main recvmsg loop, we can drop
the related race breaker.
Paolo Abeni [Sat, 27 Sep 2025 09:40:40 +0000 (11:40 +0200)]
mptcp: introduce the mptcp_init_skb helper
Factor out all the skb initialization step in a new helper and
use it. Note that this change moves the MPTCP CB initialization
earlier: we can do such step as soon as the skb leaves the
subflow socket receive queues.
Paolo Abeni [Sat, 27 Sep 2025 09:40:39 +0000 (11:40 +0200)]
mptcp: rcvbuf auto-tuning improvement
Apply to the MPTCP auto-tuning the same improvements introduced for the
TCP protocol by the merge commit 2da35e4b4df9 ("Merge branch
'tcp-receive-side-improvements'").
The main difference is that TCP subflow and the main MPTCP socket need
to account separately for OoO: MPTCP does not care for TCP-level OoO
and vice versa, as a consequence do not reflect MPTCP-level rcvbuf
increase due to OoO packets at the subflow level.
This refeactor additionally allow dropping the msk receive buffer update
at receive time, as the latter only intended to cope with subflow receive
buffer increase due to OoO packets.
Paolo Abeni [Sat, 27 Sep 2025 09:40:38 +0000 (11:40 +0200)]
tcp: make tcp_rcvbuf_grow() accessible to mptcp code
To leverage the auto-tuning improvements brought by commit 2da35e4b4df9
("Merge branch 'tcp-receive-side-improvements'"), the MPTCP stack need
to access the mentioned helper.
Paolo Abeni [Sat, 27 Sep 2025 09:40:37 +0000 (11:40 +0200)]
mptcp: leverage skb deferral free
Usage of the skb deferral API is straight-forward; with multiple
subflows actives this allow moving part of the received application
load into multiple CPUs.
Eric Dumazet [Sat, 27 Sep 2025 09:28:27 +0000 (09:28 +0000)]
tcp: use skb->len instead of skb->truesize in tcp_can_ingest()
Some applications are stuck to the 20th century and still use
small SO_RCVBUF values.
After the blamed commit, we can drop packets especially
when using LRO/hw-gro enabled NIC and small MSS (1500) values.
LRO/hw-gro NIC pack multiple segments into pages, allowing
tp->scaling_ratio to be set to a high value.
Whenever the receive queue gets full, we can receive a small packet
filling RWIN, but with a high skb->truesize, because most NIC use 4K page
plus sk_buff metadata even when receiving less than 1500 bytes of payload.
Even if we refine how tp->scaling_ratio is estimated,
we could have an issue at the start of the flow, because
the first round of packets (IW10) will be sent based on
the initial tp->scaling_ratio (1/2)
Relax tcp_can_ingest() to use skb->len instead of skb->truesize,
allowing the peer to use final RWIN, assuming a 'perfect'
scaling_ratio of 1.
Jakub Kicinski [Tue, 30 Sep 2025 01:13:51 +0000 (18:13 -0700)]
Merge tag 'for-net-next-2025-09-27' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next
Luiz Augusto von Dentz says:
====================
bluetooth-next pull request for net-next:
core:
- MAINTAINERS: add a sub-entry for the Qualcomm bluetooth driver
- Avoid a couple dozen -Wflex-array-member-not-at-end warnings
- bcsp: receive data only if registered
- HCI: Fix using LE/ACL buffers for ISO packets
- hci_core: Detect if an ISO link has stalled
- ISO: Don't initiate CIS connections if there are no buffers
- ISO: Use sk_sndtimeo as conn_timeout
drivers:
- btusb: Check for unexpected bytes when defragmenting HCI frames
- btusb: Add new VID/PID 13d3/3627 for MT7925
- btusb: Add new VID/PID 13d3/3633 for MT7922
- btusb: Add USB ID 2001:332a for D-Link AX9U rev. A1
- btintel: Add support for BlazarIW core
- btintel_pcie: Add support for _suspend() / _resume()
- btintel_pcie: Define hdev->wakeup() callback
- btintel_pcie: Add Bluetooth core/platform as comments
- btintel_pcie: Add id of Scorpious, Panther Lake-H484
- btintel_pcie: Refactor Device Coredump
* tag 'for-net-next-2025-09-27' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next: (30 commits)
Bluetooth: Avoid a couple dozen -Wflex-array-member-not-at-end warnings
Bluetooth: hci_sync: Fix using random address for BIG/PA advertisements
Bluetooth: ISO: don't leak skb in ISO_CONT RX
Bluetooth: ISO: free rx_skb if not consumed
Bluetooth: ISO: Fix possible UAF on iso_conn_free
Bluetooth: SCO: Fix UAF on sco_conn_free
Bluetooth: bcsp: receive data only if registered
Bluetooth: btusb: Add new VID/PID 13d3/3633 for MT7922
Bluetooth: btusb: Add new VID/PID 13d3/3627 for MT7925
Bluetooth: remove duplicate h4_recv_buf() in header
Bluetooth: btusb: Check for unexpected bytes when defragmenting HCI frames
Bluetooth: hci_core: Print information of hcon on hci_low_sent
Bluetooth: hci_core: Print number of packets in conn->data_q
Bluetooth: Add function and line information to bt_dbg
Bluetooth: MGMT: Fix not exposing debug UUID on MGMT_OP_READ_EXP_FEATURES_INFO
Bluetooth: hci_core: Detect if an ISO link has stalled
Bluetooth: ISO: Use sk_sndtimeo as conn_timeout
Bluetooth: HCI: Fix using LE/ACL buffers for ISO packets
Bluetooth: ISO: Don't initiate CIS connections if there are no buffers
MAINTAINERS: add a sub-entry for the Qualcomm bluetooth driver
...
====================
__ptr_ring_zero_tail currently does the - 1 operation twice:
- during initialization of head
- at each loop iteration
Let's just do it in one place, all we need to do
is adjust the loop condition. this is better:
- a slightly clearer logic with less duplication
- uses prefix -- we don't need to save the old value
- one less - 1 operation - for example, when ring is empty
we now don't do - 1 at all, existing code does it once
net: wangxun: add RSS reta and rxfh fields support
Add ethtool ops for Rx flow hashing, query and set RSS indirection table
and hash key. Disable UDP RSS by default, and support to configure L4
header fields with TCP/UDP/SCTP for flow hasing.
For global RSS and multiple RSS scheme, the RSS type fields are defined
identically in the registers. So they can be defined as the macros
WX_RSS_FIELD_* to cleanup the codes. And to prepare for the RXFH support
in the next patch, move the rss_field to struct wx.
net: libwx: support separate RSS configuration for every pool
For those devices which support 64 pools, they also support PF and VF
(i.e. different pools) to configure different RSS key and hash table.
Enable multiple RSS, use up to 64 RSS configurations and each pool has a
specific configuration.
idpf: fix mismatched free function for dma_alloc_coherent
The mailbox receive path allocates coherent DMA memory with
dma_alloc_coherent(), but frees it with dmam_free_coherent().
This is incorrect since dmam_free_coherent() is only valid for
buffers allocated with dmam_alloc_coherent().
Fix the mismatch by using dma_free_coherent() instead of
dmam_free_coherent
Fixes: e54232da1238 ("idpf: refactor idpf_recv_mb_msg") Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Madhu Chittim <madhu.chittim@intel.com> Link: https://patch.msgid.link/20250925180212.415093-1-alok.a.tiwari@oracle.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Eric Dumazet [Thu, 25 Sep 2025 23:09:29 +0000 (23:09 +0000)]
net: remove one stac/clac pair from move_addr_to_user()
Convert the get_user() and __put_user() code to the
fast masked_user_access_begin()/unsafe_{get|put}_user()
variant.
This patch increases the performance of an UDP recvfrom()
receiver (netserver) on 120 bytes messages by 7 %
on an AMD EPYC 7B12 64-Core Processor platform.
Presence of audit_sockaddr() makes difficult
to avoid the stac/clac pair in the copy_to_user() call,
this is left for a future patch.
====================
net: stmmac: Drop frames causing HLBS error
This patchset consists of following patchset to avoid netdev watchdog
reset due to Head-of-Line Blocking due to EST scheduling error.
1. Drop those frames causing HLBS error
2. Add HLBS frame drops to taprio stats
Rohan G Thomas [Thu, 25 Sep 2025 14:06:14 +0000 (22:06 +0800)]
net: stmmac: tc: Add HLBS drop count to taprio stats
Add the count of the frames dropped by Head-Of-Line Blocking due to
Scheduling(HLBS) error to taprio window drop count stats.
Signed-off-by: Rohan G Thomas <rohan.g.thomas@altera.com> Reviewed-by: Matthew Gerlach <matthew.gerlach@altera.com> Reviewed-by: Furong Xu <0x1207@gmail.com> Link: https://patch.msgid.link/20250925-hlbs_2-v3-2-3b39472776c2@altera.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Rohan G Thomas [Thu, 25 Sep 2025 14:06:13 +0000 (22:06 +0800)]
net: stmmac: est: Drop frames causing HLBS error
Drop those frames causing Head-of-Line Blocking due to Scheduling
(HLBS) error to avoid HLBS interrupt flooding and netdev watchdog
timeouts due to blocked packets. Tx queues can be configured to drop
those blocked packets by setting Drop Frames causing Scheduling Error
(DFBS) bit of EST_CONTROL register.
Also, add per queue HLBS drop count.
Signed-off-by: Rohan G Thomas <rohan.g.thomas@altera.com> Reviewed-by: Matthew Gerlach <matthew.gerlach@altera.com> Reviewed-by: Furong Xu <0x1207@gmail.com> Link: https://patch.msgid.link/20250925-hlbs_2-v3-1-3b39472776c2@altera.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Corrected function and variable name typos in comments and docstrings:
ixgbe_write_ee_hostif_X550 -> ixgbe_write_ee_hostif_data_X550
ixgbe_get_lcd_x550em -> ixgbe_get_lcd_t_x550em
"Determime" -> "Determine"
"point to hardware structure" -> "pointer to hardware structure"
"To turn on the LED" -> "To turn off the LED"
These changes improve readability, consistency.
Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Acked-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20250929124427.79219-1-alok.a.tiwari@oracle.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net: ethtool: remove duplicated mm.o from Makefile
Fixes: 2b30f8291a30 ("net: ethtool: add support for MAC Merge layer") Signed-off-by: Markus Heidelberg <m.heidelberg@cab.de> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20250926131323.222192-1-m.heidelberg@cab.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
gentwo / linux / .git / log