RTL838x devices with 28 ports produce PHY access timeout errors during
one of three boots while waiting for MDIO command completion. This is
currently set to 1ms.
Background: Access to the Realtek Otto ethernet MDIO bus must wait for
a free slot between two hardware polls. The polling sequence consists
of at least 17 commands on the RTL838x devices. This delay can be nicely
seen when disabling polling completely. The following times are measured
on a bus running on the default 2.5MHz. Time measured is from the last
register write that sets the command-start-bit until the hardware
responds with the command-finished-bit set.
- average c22 read with polling enabled on all ports: ~380us
- average c22 read with polling enabled on one port: ~380us
- average c22 read with polling completely disabled: ~180us
For this bus frequency the bare hardware runtime for a single command
(32 bit preamble + 32 bit data) is ~25us. So the hardware adds quite
some overhead. On top of this comes the fact that the RTL838x devices
are low on resources (500Mhz 4Kec core with 16K cache).
Increase the timeout to 10ms to be on the safe side.
Remark! In a future patch the bus clock frequency will be made
configurable with a minimum frequency of 1.25MHz. Setting this
(e.g. for debugging purposes) doubles the command run times but
will safely stay below 10ms.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260831143439.2404484-10-markus.stockhausen@gmx.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The hardware polling unit of the Realtek switches has a very special
handling for c22 PHY register 31 (aka Realtek page register) in place.
- On the RTL838x it is permanently reset to zero.
- On other devices there is some magic saving/restoring (aka parking)
in the background in place.
This makes access to PHYs a gamble.
It is vital to keep the polling alive so the MAC layer can rely on
consistent data. Intercept access to c22 register 31 and handle it
internally. Store the desired value for each port in the driver. When
issuing hardware access to other registers add the page to the command
towards the controller. Given this, the hardware will run two c22
commands that are not interrupted by polling.
... hardware poll ...
phy_write(phy, 31, page)
phy_write(phy, reg, value)
... hardware poll ...
Looking at this implementation one might argue that disabling/enabling
polling might be a cleaner solution. But one must remember that
- This driver differentiates clearly between C22 and C45 buses. During
probing it enables only one of the protocols for a bus.
- All known devices run RTL8218 (B/D/E) or RTL8214FC on 1G
- RTL839x gives link flapping when deactivating polling for a port
So a solution for a Realtek-only ecosystem is required. This commit
copies the downstream-proven driver-only page handling patch without
any new MDIO callbacks and is the lowest common denominator. If a
non-Realtek PHY is identified on a c22 bus the attachment aborts. It
should be noted that bus scan runs with the page handling already in
place before the check in notify_phy_attach(). This is accepted for
now.
Remark: To keep this simple, writes to register 31 are only accepted
if they are lower than the device specific raw page - 0..4094/8190.
Otherwise -EINVAL is returned. Under the above assumption (Only 1G
Realtek PHYs on a c22 bus) this is no limitation.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260831143439.2404484-9-markus.stockhausen@gmx.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
During PHY probing and configuration complex configuration sequences
might be issued and firmware might be loaded. Hardware polling can
interfere badly with that. E.g. a hardware polling MMD c45 over c22
request might break an ongoing firmware loading sequence.
To avoid such issues the polling of the Realtek Otto switches can be
(de)activated with one or two 32 bit mask registers. Each bit enables
(=1) or disables (=0) the polling of the corresponding port. Make use
of this as follows:
- Disable polling for all ports when the MDIO driver starts.
- Reenable polling just after the PHY has been attached.
- Disable polling just before the PHY is being detached.
This synchronizes the kernel and hardware polling to some extent. It
gracefully handles deferred probing of PHYs in case the driver is
loaded asynchronously during boot. Additionally it brings the hardware
polling into a consistent operation mode for devices where U-Boot does
not take care.
Important notes about the implementation:
Realtek is very inconsistent about its register naming. RTL930x uses
SMI_POLL_CTRL for polling control while it is SMI_PORT_POLLING_CTRL
on RTL931x. Keep these vendor names.
These devices do not support power management for the whole system.
So mdio_bus_phy_resume() is not used and it is not required to
disable/enable hardware polling for that usecase.
These devices have no CPU MAC to PHY design. Thus abort phy_attach()
in case PHYs are not mapped to valid switch ports. All MDIO bus
commands will fail afterwards, leaving it in an unusable state.
Enabling/disabling hardware polling is a simple regmap bit access.
For this it is enough to rely on the regmap internal lock.
This polling enabling/disabling does not solve the current inability
of the driver to handle C45-over-C22 access during normal operation.
For all existing designs this is not needed.
[1] https://github.com/openwrt/openwrt/blob/main/target/linux/realtek/files-6.18/drivers/net/mdio/mdio-realtek-otto.c#L818
[2] https://lore.kernel.org/netdev/680696024a8648535ce6dee771fe4de67802e0e8.1769053496.git.daniel@makrotopia.org/
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260831143439.2404484-8-markus.stockhausen@gmx.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The Realtek MDIO driver relies on devm managed resources for lifetime
management and allocates its internal central controller structure
otto_emdio_priv via devm_kzalloc(). This can lead to a use-after-free
in the following sitauation:
- If the driver is removed or unbound via sysfs the controller devm
cleanup is triggered immediately. A corrupt devicetree might produce
a load failure and a cleanup too.
- However the MDIO buses are allocated with devm_mdiobus_alloc_size()
and are reference counted. So if a MAC driver still holds a reference
to a PHY device on the bus, the mii_bus will remain alive.
- Any action that is run for the buses afterwards still relies on the
availability of the central priv structure. This will access already
freed memory.
There are multiple mitigations to choose from
- Clone all controller->priv data into the bus->priv structure.
- disable sysfs bind/unbind attributes
- Check for "bus->state != MDIOBUS_REGISTERED" in all callbacks
This SoC-integrated MDIO controller cannot be physically hot-plugged
and manual unbinding gives no benefit. The driver is usually
integrated into the kernel and not loaded as a module. Avoid a
complex driver rewrite (data duplication) for now and set
suppress_bind_attrs to true to prevent unbinding via sysfs. This
mitigates issues for the known use cases.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260831143439.2404484-7-markus.stockhausen@gmx.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Some MDIO buses require programming PHY polling registers depending
on the PHY type. RealTek switch SoCs are the most prominent example
of a DSA switch which doesn't allow to program MAC speed, duplex and
flow-control settings without using PHY polling to do so [1].
Avoid a half-baked solution in the MDIO bus driver because
- it must reinvent the bus scanning to determine the PHYs and
- it must anticipate the right point in time (e.g. deferred PHYs).
Hence there is a need to inform the MDIO bus driver that a PHY is
being attached or detached. Provide two hooks in struct mii_bus
- notify_phy_attach(): called in phy_attach_direct() after PHY
hardware has been initialized and just before PHY is resumed.
- notify_phy_detach(): called in phy_detach() right after PHY
has been suspended.
Worth to notice: As of now phy_detach() is not 100% LIFO symmetric
to phy_attach_direct(). E.g. sysfs links are torn down before
suspend while being created before resume. Without reordering of the
detach function the above mentioned notifier placement is the best
possible symmetric implementation. An unconditional call of
notify_phy_detach() was favoured [3].
Remark! A slightly different version of this patch was part of a
former series [2]. The discussion already showed that an initialization
hook should be placed somewhere late during the whole setup. This
commit implants it right after phy_init_hw() as suggested. On top of
this it adds the detach hook.
[1] https://github.com/openwrt/openwrt/pull/21515#discussion_r2714069716
[2] https://lore.kernel.org/netdev/cover.1769053496.git.daniel@makrotopia.org/
[3] https://lore.kernel.org/netdev/9e40f50b-357a-4a93-9f59-94847850835d@lunn.ch/#t
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260831143439.2404484-6-markus.stockhausen@gmx.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
For the upcoming MDIO bus notification enhancements the PHY detach path
needs to inform the bus about these actions. Until now phy_detach() is
used for the regular detach path as well as from the phy_attach_direct()
error paths So in the future there must be a clear indication if a
notification is needed (normal path) or not (cleanup path).
Carve out the phy_detach() code into a new helper phy_detach_internal()
and make phy_detach() a short stub that calls the new helper.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260831143439.2404484-5-markus.stockhausen@gmx.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Hardware polling breaks C45 over C22 PHY access. Currently this
is accepted by the driver but it silently fails with undefined
results. Make the situation clear to the caller by adding checks,
returning an error and giving a one-time warning message.
Suggested-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260831143439.2404484-4-markus.stockhausen@gmx.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add a detailed explanation how the hardware polling unit in the
Realtek Otto switches works. This simplifies developing future
patches and reviewing them.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260831143439.2404484-3-markus.stockhausen@gmx.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The lower end Realtek Otto switches provide 1G only and are divided into
two series:
- Maple : RTL838x up to 28 ports
- Cypress: RTL839x up to 52 ports
The Maple based devices have 3 different SoCs: RTL8380, RTL8381 and
RTL8382. The Cypress series consists of the RTL8391, RTL8392 and
RTL8393 SoCs. The MDIO controller of these switches works like the
existing RTL93xx logic but has different characteristics and different
registers. Add new compatibles in the device tree.
With the extended compatibility list change the title to better reflect
its scope. Especially add the "Ethernet" tag as these devices have
multiple MDIO controllers.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20260831143439.2404484-2-markus.stockhausen@gmx.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Mike Rapoport says:
====================
USB: replace page allocator calls with kmalloc()
This is a (small) part of larger work of replacing page allocator calls
with kmalloc.
My initial intention a few month ago was to remove ugly casts [1], but then
willy pointed out that Linus objected to something like this [2] and it
looks like more than a decade old technical debt.
Largely, anything that doesn't need struct page (or a memdesc in the
future) should just use kmalloc() or kvmalloc() to allocate memory.
kmalloc() guarantees alignment, physical contiguity and working
virt_to_phys() and beside nicer API that returns void * on alloc and
doesn't require to know the allocation size on free, kmalloc() provides
better debugging capabilities than page allocator.
Another thing is that touching these allocation sites gives the reviewers
opportunity to see if a PAGE_SIZE buffer is actually needed or maybe
another size is appropriate.
For larger allocations that don't need physically contiguous memory
kvmalloc() can be a better option that __get_free_pages() because under
memory pressure it's is easier to allocate several order-0 pages than a
physically contiguous chunk with the same number of pages.
And last, but not least, removing needless calls to page allocator should
help with memdesc (aka project folio) conversion. There will be way less
places to audit to see if the user was actually using struct page.
The patches are deliberately kept small: each one deals with a single
driver or subsystem and with a single type of allocation, so that every
conversion can be reviewed, and if needed reverted, on its own.
====================
Link: https://patch.msgid.link/20260830-usb-v1-0-aa349c302246@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
speedtch_upload_firmware() allocates a temporary buffer used to feed the
firmware to the device.
This buffer can be allocated with kmalloc() as there's nothing special
about it to go directly to the page allocator.
kmalloc() provides a better API that does not require ugly casts and
kfree() does not need to know the size of the freed object.
Performance difference between kmalloc() and __get_free_pages() is not
measurable as both allocators take an object/page from a per-CPU list for
fast path allocations.
For the slow path the performance is anyway determined by the amount of
reclaim involved rather than by what allocator is used.
Replace use of __get_free_page() with kmalloc() and free_page() with
kfree().
Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Link: https://patch.msgid.link/20260830-usb-v1-3-aa349c302246@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
cxacru_fw() allocates a temporary buffer used to feed the firmware to the
device and cxacru_bind() allocates the transfer buffers for the command
URBs.
These buffers can be allocated with kmalloc() as there's nothing special
about them to go directly to the page allocator.
kmalloc() provides a better API that does not require ugly casts and
kfree() does not need to know the size of the freed object.
Performance difference between kmalloc() and __get_free_pages() is not
measurable as both allocators take an object/page from a per-CPU list for
fast path allocations.
For the slow path the performance is anyway determined by the amount of
reclaim involved rather than by what allocator is used.
Replace use of __get_free_page() with kmalloc() and free_page() with
kfree().
Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Link: https://patch.msgid.link/20260830-usb-v1-2-aa349c302246@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Commit 71338aa7d0 ("net: convert %p usage to %pK") which is from
2011 and changed the %p annotation for pointer to %pK. Back then the
default behaviour for %p was to print the pointer. The %pK modifier was
introduced to able to control the behaviour of specific pointer values
without changing the behaviour of %p for everyone. It was dedicated to
avoid leaking pointers via /proc.
There was also the idea to remove the check from formatting the string
and move to the open callback with some helpers but this did not happen.
Things changed over time. The default behaviour for %p is now to print a
hash pointer which does not leak the address but allows to correlate if
two pointers are equal.
The policy on %p is to not introduce new ones. This is somehow in
between since it already exists. The pointer are usually socket pointers
and I don't see any value in exposing them. Therefore I am following the
recommendation of removing them. Since their usage in /proc/ can be
considered ABI I replace the pointer with a 0.
Replace the %pK annotation with 0 value. Correct the spacing for the
cases where pointer is at the beginning.
Reviewed-by: Kees Cook <kees@kernel.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: https://patch.msgid.link/20260901160345.eeknHmY2@linutronix.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
A netdevsim VF port cannot process incoming data. It never runs
nsim_queue_init(), so ns->rq is NULL, and nsim_vf_netdev_ops has no
->ndo_open, so its NAPI is never set up either.
nsim_setup() offers NETIF_F_LOOPBACK to both PF and VF ports. Turning
it on for a VF makes nsim_start_xmit() take ns itself as peer_ns and
dereference peer_ns->rq[], which panics.
A VF cannot deliver packets at all: it can't be linked as a peer either,
since netdev_is_nsim() only matches the PF netdev_ops, so ns->peer is
always NULL and every skb ends up dropped. Give VF ports a dedicated
xmit that just drops the traffic, so VFs no longer depend on PF-only
state in nsim_start_xmit().
Reproduce in qemu:
modprobe netdevsim
echo "90 1" > /sys/bus/netdevsim/new_device
echo 2 > /sys/bus/netdevsim/devices/netdevsim90/sriov_numvfs
devlink dev eswitch set netdevsim/netdevsim90 mode switchdev
ethtool -K eth2 loopback on # eth2 is the vfnum 0 port
ip link set eth2 up
Panic:
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 0 UID: 0 PID: 141 Comm: kworker/0:3 Not tainted 7.2.0+ #338 PREEMPT
Workqueue: mld mld_ifc_work
RIP: 0010:nsim_start_xmit (drivers/net/netdevsim/netdev.c:159)
dev_hard_start_xmit ( net/core/dev.c:3953)
sch_direct_xmit (net/sched/sch_generic.c:372)
__dev_queue_xmit (net/core/dev.c:4262 net/core/dev.c:4884)
neigh_resolve_output (net/core/neighbour.c:1616)
ip6_finish_output2 (net/ipv6/ip6_output.c:138)
ip6_finish_output (net/ipv6/ip6_output.c:221)
ip6_output (net/ipv6/ip6_output.c:248)
......
Cc: stable+noautosel@kernel.org # netdevsim is a test harness, it's never loaded on production systems
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Link: https://patch.msgid.link/20260901061851.61734-1-jiayuan.chen@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jakub Kicinski says:
====================
selftests: drv-net: split up gro.py
gro.py runs its full set of cases three times over - against SW GRO,
HW GRO and LRO. It's our test with the longest runtime. The 318 cases
take 12m30s on mlx5 with a debug kernel.
We will likely add more subcases here as the time goes on, so it's
time to start splitting it up. Long runtime wastes time on retries
(if any of the 300+ cases fails we try to check if it's a real failure
or flake an re-run the whole thing). It also forces us to increase
timeout for the whole test suite.
v1: https://lore.kernel.org/20260831163734.1121891-1-kuba@kernel.org
====================
Link: https://patch.msgid.link/20260901200728.2063720-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The XDP test takes 9m30s on the slowest NIC with debug kernel.
Let's give ourselves a 50% margin and set the timeout to 15min.
Reviewed-by: Joe Damato <joe@dama.to>
Reviewed-by: Nimrod Oren <noren@nvidia.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20260901200728.2063720-4-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
gro.py runs its full set of cases three times over - against SW GRO,
HW GRO and LRO. It's our test with the longest runtime. The 318 cases
take 12m30s on mlx5 with a debug kernel.
Bumping the timeout for all tests feels wrong when we can so easily
split the GRO test by execution mode. Shorter runtime also helps retry
just the failing portion / mode (we retry failing tests to try to
detect flakes vs real failures).
Move the main logic to gro_lib.py and add one program per mode -
gro_sw.py, gro_hw.py and gro_lro.py, 102 cases each. Move PPPoE to
a dedicated test. It has been tacked onto the tests in an ugly way,
and it only runs against SW GRO anyway.
Note that unfortunately this will case a rename of all test cases.
The mode moves from the case name to the test name
gro.py test.sw_ipv4_data_same
becomes
gro_sw.py test.ipv4_data_same
Reviewed-by: Joe Damato <joe@dama.to>
Reviewed-by: Nimrod Oren <noren@nvidia.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20260901200728.2063720-3-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
We need to free up the gro_hw.py name for the HW-GRO half of gro.py,
which we need to split by mode (sw / hw / lro). The file checks mostly
qstat counters, so name it after stats.
Reviewed-by: Joe Damato <joe@dama.to>
Reviewed-by: Nimrod Oren <noren@nvidia.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20260901200728.2063720-2-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The binding references ethernet-controller.yaml schema, which already
defines a dependency of pcs-handle-names on pcs-handle, thus duplicating
it here is redundant.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260901061255.25734-2-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Oleksij Rempel says:
====================
net: dsa: realtek: enable RTL8365MB power supplies
The RTL8365MB family has several external power rails (analog, digital I/O
and PLL supplies) that on some boards are gated by regulators. Until now the
driver assumed they were always on, so it could not be used on designs that
keep these rails software-controlled.
This series adds a device-tree description for those supplies and enables
them in the driver before the chip is accessed:
The supplies are optional: boards that hard-wire the rails work unchanged
====================
Link: https://patch.msgid.link/20260831123637.666457-1-o.rempel@pengutronix.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Replace the open-coded dev_err() + ERR_CAST() on the reset GPIO error
path with dev_err_cast_probe(), matching the reset controller above and
staying quiet on -EPROBE_DEFER.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Link: https://patch.msgid.link/20260831123637.666457-4-o.rempel@pengutronix.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The power supplies powering the IC may not necessarily be enabled by the
time the driver probes. The binding describes the power rails, so enable
them at probe with devm_regulator_bulk_get_enable(), before the reset line
is requested and driven, so the chip is powered before its pins are driven.
Boards that do not describe these supplies fall back to dummy regulators
(with a "supply not found" warning) and keep working as before.
A board that describes supplies but no reset line still needs to wait for
the chip to boot before the first register access, so apply the existing
start delay in that case too.
Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Co-developed-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Reviewed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Link: https://patch.msgid.link/20260831123637.666457-3-o.rempel@pengutronix.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Document the RTL8365MB power rails as optional supplies. They are optional
because the rails are often always-on; some designs break them out for
granular hwmon monitoring and regulator control.
They are scoped to realtek,rtl8365mb: different Realtek switch families use
different power-rail naming schemes, so these rails do not apply to other
families such as realtek,rtl8366rb (VDDA/VDD_CORE/VDDIO/...).
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Reviewed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20260831123637.666457-2-o.rempel@pengutronix.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Hangbin Liu says:
====================
bonding: fix TLB load-tracking overflow on high-speed NICs
The bonding TLB (Transmit Load Balancing) mode tracks per-slave and
per-client transmit byte counts in u32 fields. At sustained throughput
above ~3.2 Gbit/s over the 10-second rebalance interval these counters
wrap, causing compute_gap() to produce incorrect gap values and
mis-select transmit slaves. Such speeds are routine on modern NICs
under heavy traffic.
This two-patch series fixes the overflow by widening the relevant
fields to u64.
Patch 1 converts the unbalanced_load counter to per-cpu state as a
preparatory step. The counter sits in the transmit hot path, so
converting it to per-cpu before widening avoids introducing cross-CPU
synchronization overhead for a u64. Also use a prev_total_unbalanced
to store the previous total load to avoid reset per-cpu data.
Patch 2 widens tx_bytes, load_history, load, and the per-cpu
unbalanced_load tx_bytes from u32 to u64. It adds u64_stats_sync
protection for the per-cpu counter to prevent tearing on 32-bit
architectures, and reworks compute_gap() to use s64 arithmetic with
READ_ONCE() on slave->speed.
====================
Link: https://patch.msgid.link/20260831-bond_overflow-v6-0-ffb0ed1f7268@kylinos.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The TLB load-tracking fields tx_bytes, load_history, load, and
unbalanced_load are all u32. At sustained throughput above ~3.2 Gbit/s
over the 10-second rebalance interval the byte counters wrap, causing
compute_gap() to produce incorrect gap values and mis-select slaves.
Such speeds are common on modern NICs under heavy traffic.
Widen these fields to u64. Use u64_stats_sync to protect the per-cpu
unbalanced_load_stats against tearing on 32-bit architectures, and
div_u64() for the 64-bit divisions. The tx_bytes and load_history
are protected in spin_lock. Also protect the slave load writing in
bond_alb_monitor() with spin_lock in case of tear on 32-bit.
For compute_gap(), we still use s64 arithmetic throughout, so we can
preserve the existing calculation logic. This order of magnitude is
sufficiently large, there is no need to worry about overflow for now.
Detected by AI code review.
Cc: stable+noautosel@kernel.org # never worked
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: Hangbin Liu <liuhangbin@kylinos.cn>
Acked-by: Jay Vosburgh <jv@jvosburgh.net>
Link: https://patch.msgid.link/20260831-bond_overflow-v6-2-ffb0ed1f7268@kylinos.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
A later patch widens the bonding TLB tx counters from u32 to u64. The
unbalanced_load counter sits in the transmit hot path, and cross-CPU
synchronization of a u64 would introduce measurable overhead. Convert
unbalanced_load to a per-cpu counter first so that the subsequent
widening only touches per-cpu data local to each CPU.
Introduce struct unbalanced_load_stats to hold the per-cpu counter,
and move the aggregation into a helper, reset_unbalanced_load(), which
sums all per-cpu instances. Use the delta of current total load vs
variable prev_total_unbalanced to calculate the loading.
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: Hangbin Liu <liuhangbin@kylinos.cn>
Acked-by: Jay Vosburgh <jv@jvosburgh.net>
Link: https://patch.msgid.link/20260831-bond_overflow-v6-1-ffb0ed1f7268@kylinos.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This basically reverts the Feb 2021 change:
commit 96854bbda2 ("hv_netvsc: Restrict configurations on isolated guests")
In Feb 2021, PCI device assignment for CoCo VMs on Hyper-V was not
supported: if the host offered a PCI VF NIC device to the VM, the VM
couldn't handle it properly, so the 2021 commit was made to tell the host
"I'm unable to handle SR-IOV NICs, so please don't offer a VF to me".
If the host offers a VF NIC to the VM anyway, the change to
netvsc_receive_inband() ignores the VF NIC.
Since Mar 2023, the VM is able to support PCI device assignment due to
commit 2c6ba42168 ("PCI: hv: Enable PCI pass-thru devices in Confidential VMs")
and related commits, so hv_netvsc can functionally work with a VF NIC, but
we haven't advertised the SR-IOV capability because the MANA NIC driver
(drivers/net/ethernet/microsoft/mana/) hadn't been hardened, so a
malicious MANA NIC might be able to attack the VM.
Recently, we have finished hardening the MANA driver, so we can safely
use the MANA NIC in a CoCo VM now. Note: currently the MANA driver in a
CoCo VM still uses bounce buffering (i.e. shared decrypted memory)
for DMA. In the future, it will be able to use private encrypted
memory for DMA with the help of TDISP.
Now, advertises the SR-IOV capability for CoCo VMs.
Note: for MANA to work properly for CoCo VMs, the following earlier
commits are also required:
commit 2e2a83b499 ("net: mana: Validate the packet length reported by the NIC")
commit c72a0f09c5 ("net: mana: Sync page pool RX frags for CPU")
Note: the host might offer a VF NIC device that's not MANA -- in that
case, if the corresponding VF NIC driver isn't hardened for CoCo VMs,
the driver should be blacklisted in CoCo VMs.
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The mailbox path warns when a message claims more bytes than the descriptor
but still parses it. The attribute walkers also validate a child TLV before
proving that its declared span fits in the parent remainder.
Reject invalid mailbox message extents and bound each child attribute
before type-specific validation.
Cc: stable+noautosel@kernel.org # assumes malicious PCIe device
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Link: https://patch.msgid.link/20260830142516.38145-1-pengpeng@iscas.ac.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jakub Sitnicki says:
====================
net: Prepare skb extensions for reuse across scrubs
Following Florian's suggestion from the discussion in [1].
The skb extension allocator retains the extension's offset after the
extension is deleted. This, in theory, allows skb_ext_add() to reuse the
existing storage instead of appending another copy when an extension is
added again. However, it also means that we can't rely on the offset as an
indicator that the extension is present.
Make the extension cleanup safe, even when the offset is already allocated
and set, by making the individual extension put helpers idempotent, so that
they can be called multiple times.
This is preparatory work to support skb extension chunk area reuse after
skb scrubbing, which would be needed to persist BPF metadata skb extension
across scrubs [2].
[1] https://lore.kernel.org/ao9UV9S7rUkyQ8jv@strlen.de
[2] https://lore.kernel.org/64365932-c765-472e-bf6c-b07c9ee25eaf@kernel.org
====================
Link: https://patch.msgid.link/20260831-skb-ext-prep-work-v1-0-ecc2a8542fd9@cloudflare.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The MCTP flow extension can be released either when it is deleted from an
skb or when the last skb holding the extension block is freed. Handle the
release in __skb_ext_del(), which is currently missing, and make
skb_ext_put_mctp() safe to call from both paths.
This will let __skb_ext_put() release the MCTP key without checking whether
the extension is present first, which is needed if we want to reuse skb_ext
chunks area after skb scrubbing.
Suggested-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com>
Acked-by: Jeremy Kerr <jk@codeconstruct.com.au>
Link: https://patch.msgid.link/20260831-skb-ext-prep-work-v1-2-ecc2a8542fd9@cloudflare.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The sec_path extension can be released either when it is deleted from an
skb or when the last skb holding the extension block is freed. Make
skb_ext_put_sp() safe to call from both paths by returning when
sec_path->len is zero and clearing it after dropping the XFRM state
references.
This will let __skb_ext_put() release the sec_path without checking whether
the extension is present first, which is needed if we want to reuse skb_ext
chunks area after skb scrubbing.
Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com>
Link: https://patch.msgid.link/20260831-skb-ext-prep-work-v1-1-ecc2a8542fd9@cloudflare.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add missing enum member force-forwarding to ipv6-devconf.
In commit f24987ef69 ("ipv6: add `force_forwarding` sysctl to
enable per-interface forwarding"), the DEVCONF_* enum was extended
with DEVCONF_FORCE_FORWARDING, however Gabriel forgot to add it
to the spec.
This pre-existing issue was detected by Sashiko, when reviewing the
first patch in this series.
Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260824103816.40040-1-ast%40fiberby.net
Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de>
Reviewed-by: Gabriel Goller <g.goller@proxmox.com>
Link: https://patch.msgid.link/20260831093458.472180-4-ast@fiberby.net
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Add missing enum member accept-ra-min-lft to ipv6-devconf.
In commit 1671bcfd76 ("net: add sysctl accept_ra_min_rtr_lft")
the DEVCONF_* enum was extended with DEVCONF_ACCEPT_RA_MIN_RTR_LFT.
It was renamed to DEVCONF_ACCEPT_RA_MIN_LFT in commit 5027d54a9c
("net: change accept_ra_min_rtr_lft to affect all RA lifetimes").
Shortly thereafter, this spec was introduced in commit b2f63d904e
("doc/netlink: Add spec for rt link messages").
This pre-existing issue was detected by Sashiko, when reviewing the
first patch in this series.
Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260824103816.40040-1-ast%40fiberby.net
Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de>
Link: https://patch.msgid.link/20260831093458.472180-3-ast@fiberby.net
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
devconf is even odder than described in commit 720447bd0b
("netlink: specs: rt-link: remove implicit structs from devconf"),
where both IPv4 and IPv6 are described in an identical way:
"u32 indexed by ipv?-devconf - 1 on output, on input it's a nest".
There are two issues with that line for IPv6:
1) The subtraction is an IPv4 specific quirk, to avoid having an unused
u32 at index 0, thus saving 4 bytes per net device being dumped:
- In include/uapi/linux/ip.h the IPV4_DEVCONF_* enum begins with
IPV4_DEVCONF_FORWARDING = 1, so the enum starts at 1, which is
the reason for the subtraction in the IPv4 variant.
- In include/uapi/linux/ipv6.h the DEVCONF_* enum begins with
DEVCONF_FORWARDING = 0, so subtraction would underflow.
- ipv6_store_devconf() in net/ipv6/addrconf.c also doesn't do the
subtraction in the output path.
2) Setting IPv6 devconf through Netlink is not yet supported, as
IFLA_INET6_CONF is not handled in inet6_set_link_af().
Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de>
Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
Link: https://patch.msgid.link/20260831093458.472180-2-ast@fiberby.net
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
dwmac can do ARP offloading, where the HW replies to incoming ARP
requests. This requires multiple steps to work well :
- Program the local IP address in a dedicated register
- Enable ARP offloading
This is halfway implemented in stmmac, as it's only ever used by
selftests, and these selftests are failing on at least 2 platforms :
stm32mp1, and jh7110.
There have been some attempts in the past to support this feature, but
this never made it upstream. Let's just remove the test and that code,
until someone actually wants that to work. We should likely have a
proper API for that so that drivers can use it.
Let's also not mention ARP offload in the stmmac documentation.
Leave the defines in place and the capability detection, this doesn't
hurt and gives some information about how the IP is synthesized.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Link: https://patch.msgid.link/20260831071351.354255-1-maxime.chevallier@bootlin.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
In __stmmac_open() and stmmac_xdp_open(), the DMA engine is started
before stmmac_request_irq() is called. If the IRQ request fails, the
clean-up paths free the DMA descriptor rings via dma_free_coherent()
without stopping the DMA engine first.
With the DMA engine still running, hardware may continue to access the
descriptor ring memory after it has been freed. Add stmmac_stop_all_dma()
to both error paths, matching the teardown order in __stmmac_release().
Cc: stable+noautosel@kernel.org # untested fix to unlikely driver error path
Signed-off-by: ZhaoJinming <zhaojinming@uniontech.com>
Link: https://patch.msgid.link/32EB352EB66D74E7+20260827025415.2684733-1-zhaojinming@uniontech.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Xuanqiang Luo says:
====================
net: phy: fix cleanup after probe failure
phy_probe() initializes the PHY driver, ports, SFP upstream, and LEDs in
stages. Its error paths do not always release only the resources acquired
at each stage. It can also mark the PHY ready before all setup succeeds.
Port setup also leaves SFP cleanup split between phy_sfp_probe(),
phy_setup_ports(), and phy_probe(), and default port setup ignores errors
from attaching the port to the PHY driver.
This series makes each initialization layer own its cleanup and propagates
setup failures to the caller.
Patch 1 splits the phy_probe() cleanup by initialization stage.
Patch 2 makes SFP and port setup unwind their resources in the required
order.
Patch 3 sets PHY_READY only after LED setup succeeds.
Patch 4 calls the PHY driver remove callback after later probe failures.
Patch 5 propagates errors from default port setup.
Patch 6 prevents a double-free after partial LED trigger registration.
====================
Link: https://patch.msgid.link/20260823035600.188864-1-xuanqiang.luo@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
phy_led_triggers_register() frees phy_led_triggers when a speed trigger
registration fails, but leaves the pointer set to the freed allocation
before clearing phy_num_led_triggers.
phy_probe() ignores the registration error. If a later probe step fails,
its error path calls phy_led_triggers_unregister(); normal teardown during
an unbind or MDIO bus removal calls the same helper from phy_remove().
In either case, the trigger count is zero, so the per-trigger unregister
loop is skipped, but the dangling pointer is still freed unconditionally.
Clear the pointer when partial registration cleanup frees the array, and
make phy_led_triggers_unregister() free the array only when its pointer is
non-NULL.
Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Link: https://patch.msgid.link/20260823035600.188864-7-xuanqiang.luo@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
phy_default_setup_single_port() ignores errors from phy_add_port() and
always reports success. If a PHY driver attach_mdi_port() callback fails,
the phy_port is leaked and PHY probing continues without the expected
default port.
Destroy the port and return the error.
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Link: https://patch.msgid.link/20260823035600.188864-6-xuanqiang.luo@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
phy_probe() may fail while querying features or completing other core
initialization after the PHY driver probe callback has succeeded. The
driver core does not run the remove path after a probe error, so
resources that the PHY driver releases in its remove callback are
leaked.
Call the PHY driver remove callback on these failures.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Link: https://patch.msgid.link/20260823035600.188864-5-xuanqiang.luo@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
phy_probe() sets PHY_READY before calling of_phy_leds(). If LED setup
fails, the error path releases the initialized resources while the PHY
state remains READY even though probing failed.
Set PHY_READY only after LED setup succeeds.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Link: https://patch.msgid.link/20260823035600.188864-4-xuanqiang.luo@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Commit 4497f50286 ("net: phy: Clean the phy_ports after unregistering
the downstream SFP bus") established that an SFP upstream must be
unregistered before its phy_ports are destroyed because SFP callbacks
may access these ports.
phy_setup_ports() does not follow this order when a later port setup
step fails after phy_sfp_probe() succeeds. It destroys the SFP phy_port
and leaves phy_probe() to unregister the upstream later, creating a race
between port destruction and SFP upstream callbacks.
The error unwind is also split across three functions. If
phy_setup_sfp_port() fails, phy_sfp_probe() leaves the upstream
registered and relies on phy_probe() to remove it after
phy_setup_ports() returns.
Make each layer unwind the resources it successfully set up. Unregister
only the upstream in phy_sfp_probe() when SFP port setup fails, since
the failed port has already been destroyed. Add phy_sfp_release() for a
successful SFP probe, and make phy_setup_ports() use it before cleaning
up the remaining ports. Once phy_setup_ports() has rolled back all port
setup, make phy_probe() skip this cleanup.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Link: https://patch.msgid.link/20260823035600.188864-3-xuanqiang.luo@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
phy_probe() uses one cleanup path for failures at every initialization
stage. This runs cleanup for resources that have not been initialized.
After a successful probe and remove, phy_led_triggers_unregister() can
leave phy_num_led_triggers non-zero after freeing the trigger array. If a
subsequent probe fails before LED trigger registration, the common error
path calls phy_led_triggers_unregister() with a NULL array and stale count,
causing a NULL dereference.
Split the cleanup by initialization stage so each failure path unwinds only
the resources that may have been initialized. Unregister LED triggers
before releasing the SFP upstream and ports, because the LED triggers are
initialized after those resources and must be unwound first.
Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Link: https://patch.msgid.link/20260823035600.188864-2-xuanqiang.luo@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Current release - fix to a fix:
- netfilter: ipset: remove need to allocate memory on delete operations
Current release - regressions:
- macb: drop CONFIG_OF #if block, fix build
Previous releases - always broken:
- stream of fixes for SCTP continues
- inet: frags: strip GSO state from fragments before reassembly
- virtio-net: ensure that TCP packets don't overflow gso_segs
- tcp-ao: fix use-after-free of current_key on reconnect to another peer
- page_pool: remove zone/policy GFP flags when allocating XArray entries
- Bluetooth: L2CAP: reject accept queue add unless BT_LISTEN
- tls: device: fix out-of-bounds write in tls_append_frag()
- eth: bnxt:
- ring the doorbell when SW USO exits early, avoid packets stuck in Tx
- gate TPH enablement behind BNXT_SUPPORTS_QUEUE_API check, avoid users
of older NICs seeing non-actionable warning messages
- eth: qede: fix NULL pointer dereference in TPA fragment processing
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE6jPA+I1ugmIBA4hXMUZtbf5SIrsFAmqQojwACgkQMUZtbf5S
Irv2kg//anC58qIya/Tx3BZkpPgtbS+ki0bqb+J0a8axbItgSGEdclVtiLJn/ex0
zz9AR4Pt2DSbSUHPa7nRpdMQ2x7ZmNwNR2zqs1xClgOm5QD/2JAc53Pv81GaEKa4
O4A4TDJZfyTDsk6c0cjI3yz9uMqBt2U6pyAT6JMBIPy7/MgV+as0ETAWQlezL0sF
ZnXVg9tM3hG/8a3M88+/S1VODVJYLMucXS6pD1mqlry01SUj91elEXKiac5vCaHI
DAZaiCOmv4WV3hs7941VijPchLO64L0J+0qjGRpXiPJXQEAn4XU8QX/YNc1njgZH
tmjRWEEtLoBFcLRDUPAK9niuB5F9N3/6nnydLPLu16+exKQuCB8Bh78YHLmlrJIW
utY5ek7GtPOl31M9a5TdEGLUg5wPHSO62FhiBmTiIG4PKQym616TmOHbYJWBqFry
EPNtZ1vEJoPFNOsT1VdeD4DKVBq2UDnj/3fnphUhfvU5z+dEDdIn03+kQykwmVQT
kTuMaW4/zxR3VFjHalsI+4bvhFOEmu+/KZE07aKKm99jssDsewQHGXgYJkCPWQUk
gpnN8IVNw16ex9sfrvqje6/tshiPJJn9y/b/nGt5mq9ofgwXGmpzCPwcDgyzZKQ5
y+zVPJ0/XILHAHOBxdCklim5xiaPDYKdEI+zcEXrx/g6FraZZuI=
=1DXR
-----END PGP SIGNATURE-----
Merge tag 'net-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
Pull networking fixes from Jakub Kicinski:
"Including fixes from Bluetooth, IPSec and Netfilter.
Current release - fix to a fix:
- netfilter: ipset: remove need to allocate memory on delete operations
Current release - regressions:
- macb: drop CONFIG_OF #if block, fix build
Previous releases - always broken:
- stream of fixes for SCTP continues
- inet: frags: strip GSO state from fragments before reassembly
- virtio-net: ensure that TCP packets don't overflow gso_segs
- tcp-ao: fix use-after-free of current_key on reconnect to another
peer
- page_pool: remove zone/policy GFP flags when allocating XArray
entries
- Bluetooth: L2CAP: reject accept queue add unless BT_LISTEN
- tls: device: fix out-of-bounds write in tls_append_frag()
- eth: bnxt:
- ring the doorbell when SW USO exits early, avoid packets stuck
in Tx
- gate TPH enablement behind BNXT_SUPPORTS_QUEUE_API check, avoid
users of older NICs seeing non-actionable warning messages
- eth: qede: fix NULL pointer dereference in TPA fragment processing"
* tag 'net-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (216 commits)
inet: frags: strip GSO state from fragments before reassembly
net/sched: sch_htb: limit htb_classify inner-class filter hops
selftests/net: packetdrill: add tcp_urg_ptr_retransmit
tcp: fix corruption of urgent data on multi-segment retransmit
usb: atm: usbatm: fix invalid ci_range initialization
net: fec: only stop PTP if it was initialized
slip: remove slip_hangup() to fix use-after-free in slip_receive_buf()
net: bridge: mcast: fix use-after-free of a master VLAN's multicast context
net/sched: bound qdisc_pkt_len to prevent qdisc soft lockup
net: dsa: mxl862xx: enable assisted learning on CPU port
net: stmmac: restore NET_IP_ALIGN in the RX DMA offset
net: stmmac: drop gso_enabled_types and rely on netdev features
net: stmmac: selftests: Don't test flow control for small rx fifos
net: stmmac: selftests: Account for the UC filter list for filtering tests
net: stmmac: dwxgmac: Account for the primary MAC address for UC filtering
net: stmmac: dwmac4: Account for the primary MAC address for UC filtering
net: stmmac: dwmac1000: Account for the primary MAC address for UC filtering
net: stmmac: selftests: Check multiple MMC counters
selftests: net: Fix slow configurations in big_tcp_tunnels.sh
selftests: net: Lower threshold with csum offload off in big_tcp_tunnels.sh
...
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEjF9xRqF1emXiQiqU1w0aZmrPKyEFAmqQRZIACgkQ1w0aZmrP
KyGDXw/9G1jVJaet7bUaiAkQRIFgyarOE7VZXtUcKpxXfRBBghWfyEN3AO9VTuVj
/tQBwZUGWZnSrBOaLlTS95xD7A3TX+iQ9aMagiH6tVXGDRq3tQFxZim4BP7drdl8
R6DV1VwwHHQSeb3vMTcXPCK/W1RtMrhdkJOe8olxHp7KAfrnJl7YANdwT508PAh3
D4Wn0NWQrneEfwe31p7weMQy+w9sh5qSPb3petdwI7an9gCwhiovEtkF0X0EfkbK
OMorNc/dx56cabwI+U0y2LGn+4lJTz8U5+Z9S/KI1+x/vo1pkeeyEN5jdq9Jcuf/
Y7q08n1DbBrbbXehfe0u22ttVaENarf7SJhduw4nEOw4oIngfET/FNMbcfsj1uw4
CvRwL5hV+waI2taOdw4M1MJh0W3qU/IN+dhhigcseAacneoGULOWT9+rynNM/yKe
cfxmtFU7TFbp9L9tX6/NR1rs6Bv7oAFv98sjsGsdyhxsIZONm/KhX+CYNKfkOZmV
o8x198CR68Vb+aQTJFL6wJuX9lntMoXjazBYKQxGnzoShywsIKnOKHkvcRMofyT0
pgzXxlt9W94fnWmxwLoCdhedQjipb0GwG4pSm425nLz8GHOX+Gh+2oFayfzC6kvB
Gj41ozdfM1VQ0SI6fRr+GA2zQNIBzAQTtwT9y6VVK10ZFyR0fwU=
=Wak/
-----END PGP SIGNATURE-----
Merge tag 'nf-26-08-27' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf
Pablo Neira Ayuso says:
====================
Netfilter fixes for net
The following patchset contains Netfilter fixes for net:
1) Use DEBUG_NET_WARN_ON_ONCE() instead of WARN_ON() from the tproxy
datapath, a recent bug found a way to reach WARN_ON from datapath
due to insufficient validation of xt_TPROTO checkentry.
From Fernando F. Mancera.
2) Similar to previous patch to replace WARN_ON_ONCE by
DEBUG_NET_WARN_ON_ONCE() for connlimit. Not known issue, but
since this patch has been around for a while, let's merge it.
Also from Fernando.
3) Move nf_tables harware offload commit path after chain blob
and audit to reduce chances of leaving the hardware in
inconsistent state.
4) Add missing vzeroupper to nf_tables pipapo AVX2 to address
performace degradation to later user of SSE code,
from Eric Biggers.
5) Remove pr_debug() in x_tables extensions, a recent bogus found a
way to print a unsanitized string in xt_IDLETIMER, many of these
pr_debug() calls are there for historical reasons.
6) Use pr_info_ratelimited() in x_tables .checkentry.
7) Fix an imbalance in module refcount due to incorrect override
expression logic with sets. Remove unnecessary clone in control
plane, use the existing expressions provided by set or dynset
expression. Release override expressions only.
8) Tigthen nf_tables device name removal, it is possible to remove
prefix strings with exact device name. From Fernando F. Mancera.
9) Set on the set dead bit earlier, otherwise it is possible to
call .commit on deleted sets. This also addresses the
re-introduction of a bug.
* tag 'nf-26-08-27' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf:
netfilter: nf_tables: remove leftover set_update_list
netfilter: nf_tables: set on dead bit when performing early element removal
netfilter: nf_tables: skip double clone set expressions on element insert
netfilter: x_tables: replace pr_{info,err}() by pr_info_ratelimited()
netfilter: x_tables: remove pr_debug
netfilter: nft_set_pipapo_avx2: add missing vzeroupper
netfilter: nf_tables: move hardware offload step after building the chain blob
netfilter: conncount: use DEBUG_NET_WARN_ON_ONCE on reaching count limit
netfilter: tproxy: use DEBUG_NET_WARN_ON_ONCE for protocol fallbacks
====================
Link: https://patch.msgid.link/20260827141733.423453-1-pablo@netfilter.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
A virtio_net_hdr (tun/tap, or AF_PACKET with PACKET_VNET_HDR) can mark
an IPv4 or IPv6 fragment as GSO; nothing relates gso_type to frag_off.
inet_frag_reasm_prepare()/inet_frag_reasm_finish() keep the first
fragment's skb as the head of the reassembled datagram, including its
shinfo->gso_size/gso_type/gso_segs, and chain the remaining fragments
on frag_list with whatever linear/paged layout they arrived with.
After ip_defrag() (ip_local_deliver(), nf_defrag_ipv4, ...) the
reassembled skb therefore still claims to be GSO (SKB_GSO_DODGY), and
the next software segmentation point - udp_rcv_segment() on local
delivery, validate_xmit_skb(), or the ip_finish_output_gso() slow
path - hands it to skb_segment(). skb_segment()'s frag_list walk
assumes GRO-shaped input and hits one of its BUG_ON()s. Two writes to
a tap by an unprivileged user in its own userns are enough:
kernel BUG at net/core/skbuff.c:4899!
Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
CPU: 0 UID: 1000 PID: 82 Comm: poc Not tainted 7.2.0-pentest+ #2
RIP: 0010:skb_segment+0x20ca/0x48b0
Call Trace:
<TASK>
__udp_gso_segment+0x29a/0x27d0
udp4_ufo_fragment+0x458/0x6c0
inet_gso_segment+0x429/0x1340
skb_mac_gso_segment+0x233/0x4f0
__skb_gso_segment+0x308/0x660
udp_queue_rcv_skb+0x440/0xad0
udp_unicast_rcv_skb+0xc7/0x2c0
udp_rcv+0x16ce/0x2260
ip_protocol_deliver_rcu+0x197/0x2d0
ip_local_deliver+0x430/0x690
ip_rcv+0x16f/0x1f0
__netif_receive_skb_one_core+0x15e/0x1c0
__netif_receive_skb+0x1e/0x110
netif_receive_skb+0xf6/0x5c0
tun_rx_batched.isra.0+0x3ab/0x790
tun_get_user+0x17c3/0x3550
tun_chr_write_iter+0xba/0x1b0
vfs_write+0x646/0x1130
</TASK>
Kernel panic - not syncing: Fatal exception in interrupt
This runs with BH disabled, so it is a panic rather than an oops. The
same is reachable with CAP_NET_RAW in a netns where a defrag point
precedes a GSO point, and from a guest whose VMM forwards
virtio_net_hdr to a tap. The SKB_GSO_DODGY frag_list checks added by
commit 3dcbdb134f ("net: gso: Fix skb_segment splat when splitting
gso_size mangled skb having linear-headed frag_list") and by
commit 9e4b7a99a0 ("net: gso: fix panic on frag_list with mixed head
alloc types") do not cover it: page-backed heads skip them, and kmalloc
heads skip them when gso_size == skb_headlen(head), which the sender
controls.
An skb entering a frag queue is an IP fragment by definition and
cannot legitimately carry GSO state: GRO does not merge fragments and
the stack segments before it fragments, so only untrusted sources are
affected. This has been reachable since
commit f43798c276 ("tun: Allow GSO using virtio_net_hdr"), the first
path that let userspace attach GSO metadata to an IP fragment. Reset
the GSO fields of every fragment as it is queued, in
inet_frag_queue_insert(), which IPv4, IPv6, nf_conntrack_reasm and
6lowpan reassembly share; then neither the head nor the frag_list
members of the reassembled skb carry them (the members matter too:
the ip_do_fragment()/ip6_fragment() fast paths send them out as they
are). The head may remain CHECKSUM_PARTIAL; that is already accepted
on receive and resolved by skb_checksum_help() in
ip_do_fragment()/ip6_fragment() on forward.
Tested on top of net.git (dc4b95b8fe), x86_64: the tap reproducer
above, two further IPv4 frag_list geometries that reach
BUG_ON(i >= nfrags) and BUG_ON(!list_skb->head_frag), and an IPv6
fragment-header variant (udp6_ufo_fragment()) each panic the unpatched
kernel; with this patch all four datagrams are delivered intact and
nothing is logged.
Fixes: f43798c276 ("tun: Allow GSO using virtio_net_hdr")
Cc: stable@kernel.org
Suggested-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Xinyang Ge <xinyang@anthropic.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/937926e509f2acd8e0e66520dc2b30fd6b4d1687.1787839506.git.pabeni@redhat.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
htb_classify() follows each filter-selected inner class by switching
to cl->filter_list, but never bounds the number of hops. A filter on
an inner class can point back to itself or to another inner class that
points back, creating an infinite loop in the packet classification
path with the qdisc lock held and BH disabled — a soft lockup / panic
from a single packet.
Bound the traversal with a hop counter and drop the packet with a
rate-limited warning once the bound is exceeded. The counter is
incremented at the point the inner filter chain is picked up, after the
TC_ACT_* switch has consumed the classifier verdict, so a terminal
TC_ACT_QUEUED/STOLEN/TRAP on the last permitted chain still sets *qerr
to __NET_XMIT_STOLEN and the packet is not charged as a drop by this
qdisc or its parent.
The bound is TC_HTB_MAXDEPTH, taken from HTB's own parameters rather than
from the qdisc hierarchy depth limit. Class levels run from 0 to
TC_HTB_MAXDEPTH - 1, so a traversal that strictly descends in level can
take at most TC_HTB_MAXDEPTH hops. That descent is what a sane
configuration does, but it is assumed here rather than enforced:
htb_find() resolves a classid against every class in the qdisc, so a
filter may equally select a sibling or an ancestor. The normal
root -> inner -> leaf path takes a single hop, so the bound does not
affect legitimate classification.
htb_classify() can now return NULL irrespective of CONFIG_NET_CLS_ACT,
whereas previously every NULL return sat inside that ifdef. The NULL
handler in htb_enqueue() therefore cannot stay conditional either, so
drop the ifdef around it. This matches hfsc_enqueue(), which has always
handled a NULL class unconditionally. Without it, a kernel built
without actions would dereference a NULL class instead of dropping.
Conditions to recreate the bug:
- CONFIG_NET_SCHED, CONFIG_NET_SCH_HTB, CONFIG_NET_CLS_U32,
CONFIG_LOCKUP_DETECTOR.
- Create an HTB qdisc on a device (e.g. lo), add an inner class
1:1 with a leaf child 1:10, install a root u32 filter selecting
1:1, and an inner-class u32 filter on 1:1 also selecting 1:1.
- Send one packet (ping). On the unfixed kernel the classify loop
spins with the qdisc lock held; with softlockup_panic=1 it panics.
- Reachable from unprivileged user via unshare -Urn (CAP_NET_ADMIN).
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Reported-by: Vega <vega@nebusec.ai>
Co-developed-by: Victor Nogueira <victor@mojatatu.com>
Signed-off-by: Victor Nogueira <victor@mojatatu.com>
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260826143339.271935-1-victor@mojatatu.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
