netxen_init_module() registers the netdevice and inetaddr notifiers before
registering the PCI driver. If pci_register_driver() fails, the function
returns the error directly and leaves both notifiers registered.
That leaves notifier callbacks installed for a module that failed to load.
Mirror the module exit path on this failure and unregister the notifiers
before returning the error.
Cc: stable+noautosel@kernel.org # untested fix to unlikely driver error path
Signed-off-by: Can Peng <pengcan@kylinos.cn>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Link: https://patch.msgid.link/20260728032046.121631-2-pengcan@kylinos.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In ngbe_irq_enable(), the code subsequently calls wx_intr_enable() to
enable interrupts. However, the preceding comment incorrectly stated
"mask interrupt", which means disabling or blocking interrupts.
This patch corrects the comment to "unmask interrupt" to accurately
reflect the actual behavior of the code. No functional changes are
introduced.
Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com>
Link: https://patch.msgid.link/147244C2750FF990+20260730065409.50807-1-jiawenwu@trustnetic.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This patch adds two static helpers in drivers/net/phy/phy-c45.c to
configure and read back master-slave roles for non BASE-T1 Clause 45
PHYs via the 10GBASE-T AN control/status registers.
These helpers are wired into genphy_c45_config_aneg() and
genphy_c45_read_status(). This changes the observable ethtool output
for drivers using the generic c45 read path.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Javen Xu <javen_xu@realsil.com.cn>
Link: https://patch.msgid.link/20260728073106.1515-3-javen_xu@realsil.com.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The XGMAC DMA_MODE register has an INTM field (bits 13:12) that
controls interrupt routing behavior for DMA transfer completion
events:
00 (default): sbd_perch_* are pulse signals, sbd_intr_o is also
asserted for each completion event.
01: sbd_perch_* are level signals, sbd_intr_o is NOT
asserted for packet transfer completion events.
When multi-MSI is enabled, per-channel TX/RX interrupts are expected
to arrive on their dedicated lines. In the default INTM=00 mode,
sbd_intr_o also fires for DMA completion events, but the multi-MSI
handler stmmac_mac_interrupt() only processes MAC-layer events (LPI,
PMT, timestamps) and returns IRQ_NONE for every DMA completion
interrupt, resulting in a continuous stream of unhandled interrupts
on the common IRQ.
Hardware verification with XGMAC and multi-MSI enabled:
INTM=00: 5.4 million common IRQ interrupts in 3 seconds, ~1.8
million IRQ_NONE returns per second.
INTM=01: 0 common IRQ interrupts, per-channel IRQs work normally,
10G line rate works correctly.
Set INTM to mode 1 when multi-MSI is enabled. This matches the
existing GMAC4 implementation.
XGMAC multi-MSI has never worked correctly since it was introduced.
Signed-off-by: Zxyan Zhu <zxyan0222@gmail.com>
Reviewed-by: Qingfang Deng <qingfang.deng@linux.dev>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://patch.msgid.link/20260729023653.1162763-1-zxyan0222@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Bastien Curutchet says:
====================
net: dsa: microchip: add PTP support for KSZ8463
This series adds PTP support for the KSZ8463.
The KSZ8463 differs quite a lot from other KSZ switches supporting PTP:
it has a different interrupt logic and a different 'PTP engine'.
This third iteration addresses two more Sashiko comments from v2. I
didn't address some other Sashiko comments, I said why in the v2 thread.
Patches 1 to 4 add interrupt support for the KSZ8463
Patches 5 to 10 add the PTP support for the KSZ8463
====================
Link: https://patch.msgid.link/20260727-ksz-new-ptp-v3-0-caba39e680e3@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The KSZ8463 switch supports PTP but it's not supported by the driver.
Add L2 two-step PTP support for the KSZ8463. IPv4 and IPv6 layers aren't
supported. Neither is one-step PTP. Use KSZ8463-specific implementations
of the .get_ts_info and .port_hwtstamp_set callbacks.
The pdelay_req and pdelay_resp timestamps share one interrupt bit status
while they're located in two different registers. So introduce
last_tx_is_pdelayresp to keep track of the last sent event type. This
flag is set by the xmit worker right before sending the packet and then
used in the interrupt handler to retrieve the timestamp location.
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260727-ksz-new-ptp-v3-10-caba39e680e3@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Detection of L2 PTP frames needs to be enabled for PTP to work at the L2
layer. The bit enabling this detection is set by default on the switches
currently supported by the driver, but it is unset by default on the
KSZ8463 for which support will be added in upcoming patches.
Explicitly enable the detection of L2 PTP frames for all switches when
PTP is enabled.
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260727-ksz-new-ptp-v3-9-caba39e680e3@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
KSZ8463 uses the KSZ9893 DSA TAG driver. However, the KSZ8463 doesn't
use the tail tag to convey timestamps to the host as KSZ9893 does. It
uses the reserved fields in the PTP header instead.
Add a KSZ8463-specific DSA_TAG driver to handle KSZ8463 timestamps.
There is no information in the tail tag to distinguish PTP packets from
others so use the ptp_classify_raw() helper to find the PTP packets and
extract the timestamp from their PTP headers.
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260727-ksz-new-ptp-v3-8-caba39e680e3@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
KSZ8795 and KSZ9893 have very similar tag handling in the xmit path,
leading to code duplication.
There are only two differences between the two ksz*_xmit():
- the KSZ8795 doesn't handle priorities between frames
- ksz8795_xmit() directly returns the SKB instead of calling
ksz_defer_xmit(). Yet, ksz_defer_xmit() also returns directly the SKB
if no clone is present inside the SKB. Clones are only created by the KSZ
driver when the PTP feature is enabled. Since KSZ8795 doesn't support
PTP, returning the SKB directly or ksz_defer_xmit() is the same.
The upcoming support for the KSZ8463 also requires a similar xmit().
Gather the common code from ksz8795_xmit() and ksz9893_xmit() into a new
ksz_common_xmit() function that takes three input arguments:
- do_tstamp to tell whether ksz_xmit_timestamp() should be called
- prio to give the priority tag (if any)
- override_mask to give the location of the override bit (if any)
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260727-ksz-new-ptp-v3-7-caba39e680e3@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Upcoming patch reduces code duplication between KSZ8795 and KSZ9893 by
introducing a common xmit() function. This rework needs the KSZ8795
handlers to be implemented below ksz_defer_xmit().
Do the move now to reduce the noise in next patch.
No functionnal change is intended in this patch.
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260727-ksz-new-ptp-v3-6-caba39e680e3@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In KSZ8463 register's layout, the offset between port 1 and port 2
registers isn't the same in the generic control register area than in
the PTP register area. The get_port_addr() always uses the same offset
so it doesn't work when it's used to access PTP registers.
Adapt the port offset in get_port_addr() when the accessed register is
in the PTP area.
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260727-ksz-new-ptp-v3-5-caba39e680e3@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
KSZ8463 PTP interrupts aren't handled by the driver.
The interrupt layout in KSZ8463 has nothing to do with the other
switches:
- Its global interrupt enable register is 16-bits long and follow an
'enable' logic, instead of a 'mask' one
- all the interrupts of all ports are grouped into one status register
while others have one interrupt register per port
- xdelay_req and pdresp timestamps share one single interrupt bit on the
KSZ8463 while each of them has its own interrupt bit on other switches
Create a KSZ8463-specific set of interrupt domain operations to handle
the global IRQ layer. To limit code duplication, it uses the same
interrupt handler than the other switches. Since other switches have
8-bits registers, only the high-byte of the interrupt status/enable
registers are used. This high-byte is where the PTP interrupts are
located. The low-byte contains the wake-up detection interrupts so if at
some points these interrupts are needed we'll need a bit of rework here.
Create KSZ8463-specific functions to setup the PTP interrupts. The
created IRQ domain is tied to the first port of the KSZ8463. Again,
the same PTP interrupt handler than the others switches is used.
Implement the teardown callback to release the interrupts.
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260727-ksz-new-ptp-v3-4-caba39e680e3@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The IRQ setup uses an hardcoded set of IRQ operations. These operations
don't fit with the KSZ8463 which has an inverted bit logic (it uses an
'enable irq' register instead of a 'mask irq' one) and 16-bits registers.
Take the IRQ domain operations as input of ksz_irq_common_setup() to
allow KSZ8463 to use the already existing setup with its own set of IRQ
operations.
Expose ksz_irq_common_setup() and ksz_irq_bus_lock/unlock() so they can
be used by ksz8.c.
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260727-ksz-new-ptp-v3-3-caba39e680e3@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
ksz8_config_cpu_port() is only called twice, once by ksz8_setup() and
once by ksz8463_setup(). It contains a ksz8463 branch that could be
avoided in the ksz8_setup() case and a ksz87xx/ksz88xx branches that
could be avoided in ksz8463_setup() case.
Create ksz8463_config_cpu_port() that only handles the ksz8463 case and
remove the ksz8463 specificities from the common ksz8_config_cpu_port().
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260727-ksz-new-ptp-v3-2-caba39e680e3@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
KSZ8463 uses the ksz8_setup() as setup() callback for its DSA
operations. Its behavior is quite different than other KSZ8 switches,
especially its interrupt scheme.
Remove from the ksz8_setup()/ksz8_reset_switch() everything that is
ksz8463-related.
Create a dedicated ksz8463_setup() and a ksz8463_reset_switch() function.
This new ksz8463_setup() is widely inspired from ksz8_setup, it has
following differences:
- it doesn't configure drive strength (not supported on KSZ8463)
- it uses the ksz8463_reset_switch()
- it doesn't call ksz8_handle_global_errata() (the handled errata only
affects the KSZ87xx variant)
- it doesn't configure IRQs. Note that ksz8_setup()'s IRQ initialization
doesn't work for the KSZ8463 anyway. Proper support for it comes in
upcoming patches.
Remove the teardown implementation from the KSZ8463 operations. Since
PTP and interrupts aren't setup, the common ksz_teardown() wouldn't do
anything anyway.
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260727-ksz-new-ptp-v3-1-caba39e680e3@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jeremy Kerr says:
====================
net: mctp: usb: Add support for MCTP-over-USB v1.1
Version 1.1.0 of DSP0283 (MCTP over USB transport binding) has been
released, this patch series updates our current v1.0.1 support for the
changes in v1.1.x.
The major change in v1.1 is the introduction of "packet spanning" mode,
where a single MCTP packet may be split over multiple USB packets
(themselves forming a single USB bulk transfer). This relaxes the
requirement for USB high-speed mode, as we can now send MCTP packets
contained over multiple 64-byte full-speed USB bulk transfers, and gives
us an increase in the maximum MCTP packet size - we now have 13 bits of
packet length (previously 8) in the transport header.
Handling packet spanning introduces some complexity in the transmit and
receive paths, as we lose some constraints on where packet boundaries
may correspond to USB transfer boundaries, and may need to retain state
across separate transfers. To contain this complexity, we introduce a
new library for the transfer packing- and unpacking implementations,
"mctp-usblib". The host driver is a consumer of this library, and a
future gadget driver can use the same implementations. We can now also
implement tests on the API boundary of the library.
The series implements an incremental shift to mctp-usblib, then
implements packet spanning mode in the new library. We have a few
changes to prepare for this, in altering a few constants and
behaviours as v1.0-specific. Once packet spanning is implemented in
mctp-usblib, we enable it in the host-side driver.
====================
Link: https://patch.msgid.link/20260724-dev-mctp-usb-1-1-v5-0-e66bbba0dbdc@codeconstruct.com.au
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Currently, we stop tx queues when we have one urb submitted. This means
we will immediately hit dev_hard_start_xmit's tx-queues-off ->
NETDEV_TX_BUSY case, and revert to the requeue -> gso_skb single-dequeue
path, and no longer be able to pack skbs without an xmit_more
indication.
Instead, allow a few urbs to be in-flight, with a limit of 16kB of data
outstanding (after which we will disable queues). With this, the tx path
will cause fewer requeues (and therefore non-packed transfers) under
normal loads.
Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au>
Link: https://patch.msgid.link/20260724-dev-mctp-usb-1-1-v5-12-e66bbba0dbdc@codeconstruct.com.au
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Using the existing prepare/complete API, we can persist the rx skb
across receives to implement v1.1 packet spanning.
Alter the packet-extraction loop to allow truncated packets, returning
early with the skb persisted for the next IN urb completion. When we see
we have a complete packet, netif_rx() that. If the packet boundary
aligns with the urb completion, we can netif_rx() the whole thing.
Those intermediate packets are cloned from the original
(large-transfer-data) skb. Unlike existing behaviour, if the clone
fails, we drop just that clone, instead of the existing transfer skb.
This allows us to process the rest of the skb data, and any continuation
of the span into the next transfer.
One subtle change: the mctp_usblib_rx() helper now handles skbs with the
full transport header, so we shift the skb_pull() for the header data to
the helper, before doing the rx_bytes stats update.
We still need to handle non-spanning mode, so error out on
truncated-packet cases there.
Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au>
Link: https://patch.msgid.link/20260724-dev-mctp-usb-1-1-v5-8-e66bbba0dbdc@codeconstruct.com.au
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In the v1.1 update to DSP0283, we have a larger header field, of 13 bits
rather than 8.
In order to accommodate this, in preparation for proper v1.1 support,
expand our struct mctp_usb_hdr's len field to a u16, and endian-convert
when necessary. Because we don't yet support spanning mode, we will
never receive or transmit with the top 5 bits set, so we always mask
out anyway.
This allows for a future change where we allow spanning mode with
>512-byte transfers.
Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au>
Link: https://patch.msgid.link/20260724-dev-mctp-usb-1-1-v5-7-e66bbba0dbdc@codeconstruct.com.au
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The MCTP over USB spec allows us to pack multiple packets in one
transfer. Given the packet max length is 255, and the transfer max
length is 512, we can typically include two full-size packets per
urb submission.
To do this, we allow a struct mctp_usb_tx to persist a tx_ctx,
representing the ongoing context for a transmit. If possible, a TX skb
will be queued to the context and the send deferred until the context is
full, or the device queue reports no more packets.
This typically requires a linear buffer for the 512-byte TX, which we
allocate along with the TX context.
Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au>
Link: https://patch.msgid.link/20260724-dev-mctp-usb-1-1-v5-6-e66bbba0dbdc@codeconstruct.com.au
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
With the RX processing in mctp-usblib, add TX processing alongside.
To accommodate packed transfers in DSP0283, where a transfer may contain
multiple MCTP packets, we move to a split process for the transmit API:
* push: create a new transmit context, and add a skb to it.
* send: callback to the driver implementation to send the (possibly
multi-packet) USB transfer
* complete: update skb accounting and release the tx context
The actual multi-packet transfer implementation will be added in the
next change; no tx context persists beyond the single send at present.
However, we use an anchor in the host driver implementation to track the
submitted TX urb when necessary.
While we're here, fix an inconsistency between tx and rx stats: both
should not include the transport header.
Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au>
Link: https://patch.msgid.link/20260724-dev-mctp-usb-1-1-v5-5-e66bbba0dbdc@codeconstruct.com.au
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Currently, we give-up on all non-zero status values on our IN/rx urb,
and do not re-queue the urb. This will stall the driver, and prevent
any further receive.
Instead, attempt a re-queue on transient errors, with a max of ten
successive failures. Handle EPIPE specially, by scheduling a
usb_clear_halt() in non-atomic context.
Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au>
Link: https://patch.msgid.link/20260724-dev-mctp-usb-1-1-v5-4-e66bbba0dbdc@codeconstruct.com.au
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The processing of USB receive transfers is common to both sides of a
MCTP over USB transport. In order to support a future gadget driver,
move the current host-side driver into a new common file, mctp-usblib.
This currently handles the submit-complete-packetise process of the
receive path of the USB transport. We'll add transmit handling in an
upcoming change.
Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au>
Link: https://patch.msgid.link/20260724-dev-mctp-usb-1-1-v5-3-e66bbba0dbdc@codeconstruct.com.au
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jack Ma says:
====================
net: nexthop: per-nexthop UDP dst port for fdb (VXLAN) nexthops
FDB nexthops let a VXLAN fdb entry point at a group of remote VTEPs, with the
kernel flow-hashing across the group (commit 1274e1cc42 ("vxlan: ecmp support
for mac fdb entries")). Each leg carries its own remote IP, but the UDP
destination port is always taken from the VXLAN device (vxlan->cfg.dst_port)
and cannot be set per leg.
This series adds an optional per-nexthop UDP destination port for fdb nexthops,
so a group's legs can share a remote IP and differ only in UDP port.
Motivation
The deployment runs an overlay in which each tenant's traffic is terminated by
a "forwarder": a pod that hosts the VXLAN VTEP, decapsulates the tenant's
overlay, and relays it to and from that tenant's workload. Forwarders for many
different tenants are packed onto the same receiver node behind one
mesh-routable underlay IP, and are demultiplexed purely by UDP destination
port. The host does a stateless outer-UDP demux by port; it never terminates
the tunnel:
receiver node -- one mesh-routable underlay IP (NodeIP_A)
+----------------------------------------------------+
| host netns: stateless outer-UDP demux by dst port |
| (host does NOT terminate the tunnel) |
| |
| dst :40000 dst :40001 dst :40002 |
| | | | |
| +-----v----+ +-----v----+ +-----v----+ |
| | pod0 ns | | pod1 ns | | pod2 ns | |
| | vxlan | | vxlan | | vxlan | |
| | VTEP | | VTEP | | VTEP | |
| | decap | | decap | | decap | |
| +----------+ +----------+ +----------+ |
+----------------------------------------------------+
(up to ~10 forwarder pods packed per node)
The packed pods are unrelated: each belongs to a different tenant on its own
VXLAN VNI, so the per-pod UDP port is node-level demux, not an HA construct.
The host, which only demuxes outer UDP, never has to reason about tenancy.
A single forwarder is made highly available by running replicas. The replicas
of one forwarder share a single anycast overlay identity: one inner MAC and IP.
Clients address that one identity, and a sender spreads flows across the live
replicas with an fdb nexthop group. Failover is transparent: a dead replica is
just dropped from the group, with no client re-resolution or route change. The
single identity is deliberate; the endpoint is consumed one layer up as a
single stable address, so giving each replica its own address would push
multi-address handling and health-checking up into that consumer.
Anti-affinity keeps the two replicas of one HA set on different nodes, so a
group's legs land on distinct node IPs. But each leg is still reachable only
at (node IP, that pod's UDP port), so within one group the legs differ in IP
*and* port. A group can already carry a distinct IP per leg, but it takes the
UDP port from the device (a single value), so it cannot send each leg to its
own port. That is the gap this series closes.
Zooming into one forwarder pod, there is nothing for the host to load-balance:
the tunnel terminates on a vxlan device inside the pod's own netns, and the pod
reaches its tenant through a separate NIC:
one forwarder pod -- its own netns, tenant VNI X
+-------------------------------------------------+
| |
| on/off-ramp NIC <--- customer data plane |
| | on-ramp (ingress) / off-ramp (egress) |
| | inner packet |
| vxlan (VTEP) encap / decap for VNI X, |
| | listens on this pod's UDP port |
| | outer VXLAN UDP |
| eth0 (underlay) NodeIP:port |
| | to peer VTEPs over the |
| v mesh underlay |
| |
+-------------------------------------------------+
Existing mechanisms do not fit this shape:
- L3 multipath in the overlay needs each leg to be a distinct routable
nexthop with its own address. Since an HA set is a single anycast address
by design, there are no distinct per-leg addresses to route over; the fdb
nexthop group bridging to that shared MAC is what load-balances.
- Host-side fan-out (XDP / TC / SO_REUSEPORT) assumes a shared host datapath
that is not there. SO_REUSEPORT balances sockets within one netns, but the
receivers are in different netns (in fact different tenants). An XDP/TC
fan-out would require the host to terminate the tunnel and re-dispatch
inner traffic across netns and VNI boundaries, i.e. become a VTEP, which
puts the host into the tenant datapath and largely duplicates what an fdb
nexthop group already does.
- Demuxing on VNI instead of port (one shared 4789 socket, multiple vxlan
devices differing only in VNI, moved into each pod's netns) works when the
co-located pods have different VNIs. It does not help two same-VNI HA sets
on one node: their outer headers are identical, so the host would again
have to terminate the tunnel to tell them apart. It also costs packing
density: with one shared underlay IP, VNI demux allows at most one VTEP per
(VNI, node), so N same-VNI HA sets of two replicas need 2N nodes, whereas a
per-pod port fits them on two nodes with anti-affinity preserved.
This series adds the attribute:
- Patch 1 adds a netlink attribute NHA_DST_PORT (__be16, mirroring NDA_PORT),
stored in struct nh_info and echoed back on dump. It is only accepted
together with NHA_FDB and NHA_GATEWAY. Control-plane only; datapath
behaviour is unchanged.
- Patch 2 wires it into the VXLAN datapath: vxlan_fdb_nh_path_select() sets
rdst->remote_port to the selected leg's port. vxlan_xmit_one() already
prefers rdst->remote_port when non-zero and otherwise falls back to the
device port, so nexthops without a port are unaffected (backward
compatible).
- Patch 3 extends the fdb nexthop selftests.
On the uAPI: this does not add a new datapath concept. A single fdb entry
already carries a per-destination UDP port (NDA_PORT), and vxlan_xmit_one()
already prefers rdst->remote_port when set. NHA_DST_PORT is the nexthop analog
of that existing attribute: control-plane only, no datapath change, and
backward compatible (a leg with no port falls back to the device port as
today). It sits at the nexthop level rather than under NHA_ENCAP because fdb
nexthops do not use the NHA_ENCAP / LWT infrastructure.
Example:
ip nexthop add id 1 via 192.0.2.10 fdb dst_port 4789
ip nexthop add id 2 via 192.0.2.10 fdb dst_port 5789
ip nexthop add id 10 group 1/2 fdb
bridge fdb add 00:11:22:33:44:55 dev vxlan0 nhid 10
Both legs share gateway 192.0.2.10 and differ only in UDP port; the kernel
hashes flows across them.
====================
Link: https://patch.msgid.link/20260724-b4-vxlan-fdb-port-v5-0-cd1c6aeee058@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add coverage for the new per-nexthop VXLAN destination port
(NHA_DST_PORT).
In fib_nexthops.sh, new ipv4_fdb_port_fcnal() and ipv6_fdb_port_fcnal()
tests check that a dst_port is accepted on an fdb nexthop that has a
gateway and echoed back on dump, that it is rejected without a gateway
and rejected when zero, that a group may hold legs that differ only in
UDP port, and that a portless fdb nexthop omits the attribute. The
tests SKIP when iproute2 lacks the "dst_port" keyword.
In test_vxlan_nh.sh, basic_tx_common() gains a second fdb nexthop group
whose nexthop carries a destination port that differs from the VXLAN
device default, plus a flower filter keyed on that port, to confirm the
per-nexthop port is used on the wire. The test now requires an iproute2
with dst_port support.
Signed-off-by: Jack Ma <jack4it@gmail.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Link: https://patch.msgid.link/20260724-b4-vxlan-fdb-port-v5-3-cd1c6aeee058@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
When an fdb entry points at a nexthop group, vxlan_fdb_nh_path_select()
resolves the selected leg's remote IP but leaves the UDP destination port
at the device default (vxlan->cfg.dst_port).
Extend nexthop_path_fdb_result() to also return the selected nexthop's
NHA_DST_PORT (0 when unset) and have vxlan_fdb_nh_path_select() store it
in rdst->remote_port. vxlan_xmit_one() already prefers rdst->remote_port
when non-zero and falls back to the device port otherwise, so nexthops
without a port are unaffected.
This lets one fdb nexthop group load-balance a flow across legs that
share an underlay IP but differ in UDP destination port.
Signed-off-by: Jack Ma <jack4it@gmail.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Link: https://patch.msgid.link/20260724-b4-vxlan-fdb-port-v5-2-cd1c6aeee058@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Commit 1274e1cc42 ("vxlan: ecmp support for mac fdb entries") lets a
single inner MAC be reached through a group of remote VTEPs, with the
kernel flow-hashing across the group members. Each member carries its
own remote IP, but the UDP destination port is always taken from the
VXLAN device (vxlan->cfg.dst_port) and cannot be set per member.
Some deployments pack several receivers behind one underlay IP and tell
them apart by UDP port, so they need a per-nexthop destination port to
spread flows across (IP, port) tuples rather than IP alone.
Add a netlink attribute NHA_DST_PORT (__be16, mirroring NDA_PORT) that
carries an optional UDP destination port on an fdb nexthop. It is only
accepted together with NHA_FDB and NHA_GATEWAY; it is stored in struct
nh_info and echoed back on dump. The attribute is named generically
rather than fdb-specific so it can be reused should another nexthop type
ever need a destination port. This patch is control-plane plumbing
only; the VXLAN datapath is wired up in a follow-up patch, so behaviour
is unchanged for now.
Signed-off-by: Jack Ma <jack4it@gmail.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Link: https://patch.msgid.link/20260724-b4-vxlan-fdb-port-v5-1-cd1c6aeee058@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Pull networking fixes from Paolo Abeni:
"This is again larger than usual: the backlog accumulated in the past weeks
is not done yet. I'm not aware of any known pending regression.
Including fixes from netfilter, Bluetooth, WiFi and CAN.
Current release - regressions:
- bluetooth: remove unnecessary hci_conn_get in create_conn_sync
- can: isotp: fix timer drain order, wakeup handling and tx_gen
ordering
- eth:
- tun/vhost: revert avoid ptr_ring tail-drop when a qdisc is
present
Previous releases - regressions:
- core: do not send ICMP/NDISC Redirects when peer allocation fails
- ipv6: take nexthop lock for f6i_list walks in replace check and
notify
- wifi: fix an ath12k MLO regression impacting WCN7850/QCC2072.
- netfilter: nf_tables: make nft_object rhltable per table
- af_unix: fix listen() succeeding on sockets in the wrong state
- openvswitch: fix potential UAF on meter attach failure
- bluetooth:
- fix advertising data UAFs
- avoid deadlocks in iso_sock_timeout
- smc: fix socket use-after-free during link group termination
- dpll: use pin owner's dpll ref for pin-level attribute reporting
- eth:
- veth: convert frag_list skbs before running XDP
- ice: wait for reset completion in ice_resume()
- igc: remove napi_synchronize() in igc_down()
- vxlan: use pskb_network_may_pull() for transmit path header pulls
Previous releases - always broken:
- xsk: fix AF_XDP multi-buffer Tx descriptor reclaim
- psp: fix NULL genl_sock deref race with concurrent netns teardown
- netfilter: widen NAT rewrite delta to s32 in sip_help_tcp()
- can: peak_usb: fix double free of transfer buffer on URB submit error
- dibs: fix use-after-free of dmb_node in loopback attach/detach/unregister
- sctp: prevent peer transport count overflow
- dsa: mt7530: error out on failed reads in MT7531 PHY polling
- eth:
- idpf: bound interrupt-vector register fill to the allocated array"
* tag 'net-7.2-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (156 commits)
qede: sync udp_tunnel ports outside qede_lock in the recovery path
net: openvswitch: fix potential UAF on meter attach failure
octeontx2-pf: Set correct sequence for carrier off and tx queue stop
net: libwx: fix FDIR ATR queue mismatch for software VLAN packets
net: dsa: realtek: use devm_mutex_init for l2_lock
net: dsa: realtek: use devm_mutex_init for vlan_lock
net: dsa: realtek: use devm_mutex_init for regmap lock
net: dsa: realtek: rtl8365mb: use devm_mutex_init for mib_lock
ptp: netc: fix potential interrupt storm caused by incorrect unbind order
net: mana: Return error code from mana_create_rxq()
net: openvswitch: fix skb leak on flow key update failure during ct
net: openvswitch: fix skb leak on flow key update failure during recirculation
net: stmmac: Fix E2E delay mechanism
net: dsa: mt7530: error out on failed reads in MT7531 PHY polling
net: dsa: mt7530: error out on failed reads in ATC/VTCR command polling
net: dsa: mt7530: check bus->read() errors in the MDIO regmap backend
Revert "tun/tap: add ptr_ring consume helper with netdev queue wakeup"
Revert "vhost-net: wake queue of tun/tap after ptr_ring consume"
Revert "ptr_ring: move free-space check into separate helper"
Revert "tun/tap & vhost-net: avoid ptr_ring tail-drop when a qdisc is present"
...
Pull gpio fixes from Bartosz Golaszewski:
- fix a memory leak in gpio-sloppy-logic-analyzer
- fix a regression in GPIO hog handling for hogs without direction
specified
- extend the critical section in IRQ handling in gpio-pca953x to cover
the reads from the direction register
- disable the interrupt on errors when restoring context in
gpio-pca953x
- apply the initial value when setting direction in gpio-by-pinctrl
- use raw spinlock for the register lock in gpio-pch to address locking
context issues
* tag 'gpio-fixes-for-v7.2-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
gpio: pch: use raw_spinlock_t for the register lock
gpio: pca953x: fix cache_only and IRQ state on restore_context() failure
gpio: gpio-by-pinctrl: Apply initial value in direction output wrapper
gpio: pca953x: fix pca953x_irq_bus_sync_unlock regmap lock
gpiolib: tolerate gpio-hogs lacking a hogging state
gpio: sloppy-logic-analyzer: Fix memory leak in gpio_la_poll_probe()
Pull powerpc fixes from Madhavan Srinivasan:
- ensure vpa,slb_shadow & dtl are unregistered during crash
- fix nap return address corruption on async interrupt exit in 970
platform
- fix exit_flags field placement in pt_regs for ptrace
- fix map failure path in dma_ioc0_map_pages() in ps3 platfrom
- MAINTAINERS: Michael Ellerman demotes himself to reviewer
- misc fixes and cleanup
Thanks to Amit Machhiwal, Andreas Schwab, Anushree Mathur, Athira
Rajeev, Christophe Leroy (CS GROUP), Dmitry V. Levin, Geert
Uytterhoeven, John Ogness, Michael Ellerman, Mukesh Kumar Chaurasiya
(IBM), Ritesh Harjani (IBM), Thorsten Blum, and Vaibhav Jain
* tag 'powerpc-7.2-3' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
MAINTAINERS: Demote myself to reviewer
powerpc/serial: Fix include guard comment
powerpc/perf: Use strstarts() to simplify is_thread_imc_pmu()
powerpc/ps3: Fix map failure path in dma_ioc0_map_pages()
powerpc/ps3: Remove unused struct table in setup_areas()
powerpc/boot: Fix treeboot-akebono CPU node lookup check
powerpc/boot: Fix treeboot-currituck CPU node lookup check
powerpc/boot: Fix simpleboot CPU node lookup check
powerpc: Fix exit_flags field placement in pt_regs for ptrace
powerpc/970: fix nap return address corruption on async interrupt exit
powerpc/pseries: Skip vpa_init() for boot cpu in smp_setup_cpu()
powerpc/pseries: Ensure vpa,slb_shadow & dtl are unregistered during crash
A TX timeout on a qede NIC that has VXLAN/GENEVE tunnel ports
configured wedges the rtnetlink control plane of the whole machine:
NETDEV WATCHDOG: ens6f1 (qede): transmit queue 2 timed out 10226 ms
[qede_tx_timeout:586(ens6f1)]TX timeout on queue 2!
[qede_recovery_handler:2665(ens6f0)]Starting a recovery process
The recovery path deadlocks on the driver's own mutex:
qede_sp_task
rtnl_lock()
mutex_lock(&edev->qede_lock) <- taken
qede_recovery_handler
qede_load
udp_tunnel_nic_reset_ntf
__udp_tunnel_nic_device_sync
info->sync_table == qede_udp_tunnel_sync
mutex_lock(&edev->qede_lock) <- same task: deadlock
The mutex is not recursive, so the kworker blocks on itself with
rtnl_lock held, and neither lock is ever released. Every task that
calls rtnl_lock() afterwards (ip, ovs-vswitchd, lldpad, IPv6
addrconf, sshd) blocks forever while the node still answers ping.
In a vmcore from an affected production node rtnl_mutex.owner
decodes to the very kworker blocked at the innermost mutex_lock()
above.
Re-sync the tunnel ports from qede_sp_task() after the internal lock
is dropped, still under rtnl_lock as the udp_tunnel API requires.
This mirrors qede_open(), which calls udp_tunnel_nic_reset_ntf()
under rtnl without the internal lock.
qede_recovery_handler() now returns whether it has successfully
reloaded an open device, and the caller re-syncs the ports only in
that case. This keeps the old gating exactly: a device that was down
or a failed recovery returns false, as those paths never reached the
udp_tunnel_nic_reset_ntf() call before either.
This was the only user of the qede_lock()/qede_unlock() helpers, so
remove them.
Fixes: 8cd160a294 ("qede: convert to new udp_tunnel_nic infra")
Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Andrew Lunn <andrew+netdev@lunn.ch>
CC: "David S. Miller" <davem@davemloft.net>
CC: Eric Dumazet <edumazet@google.com>
CC: Jakub Kicinski <kuba@kernel.org>
CC: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Link: https://patch.msgid.link/20260726104311.1782900-1-den@openvz.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Marc Kleine-Budde says:
====================
pull-request: can 2026-07-29
this is a pull request of 20 patches for net/main.
The first 2 patches fix problems in the CAN J1939 protocol and are by
Tetsuo Handa and Oleksij Rempel.
The next 2 patches fix problems in the CAN ISOTP protocol and are by
Oliver Hartkopp and Minhong He.
Avi Weiss contributes contributed 4 fixes for the ctucanfd, Pengpeng
Hou's patch adds a missing MODULE_DEVICE_TABLE.
The patches for the peak_usb driver are contributed by James Gao,
Maoyi Xie, Maoyi Xie and add sanity checks for the USB bulk data
parsing and fix a double free.
2 fixes for the kvaser_usb driver are provided by Abdun Nihaal and
Pengpeng Hou, a mem leak is fixed and sanity checks for the USB bulk
data parsing.
Tu Nguyen's patch for the rcar_canfd driver fixes the initializing
flow.
Pengpeng Hou contributes a patch for the softing driver to validate
the firmware record spans.
Lucas Martins Alves's patch for the c_can driver keeps the controller
in init mode until configuration is complete.
A patch by my add missing URB resubmission on skb allocation failure
to the gs_usb driver.
Guangshuo Li's patch for the etas_es58x driver fixes a RX buffer leak.
The last patch is by Pengpeng Hou and adds sanity checks to the USB
bulk data parsing of the ems_usb driver.
linux-can-fixes-for-7.2-20260729
* tag 'linux-can-fixes-for-7.2-20260729' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can:
can: ems_usb: validate CPC message lengths
can: etas_es58x: es58x_read_bulk_callback(): fix RX buffer leak on URB resubmit failure
can: gs_usb: gs_usb_receive_bulk_callback(): resubmit URB on skb allocation failure
can: c_can: c_can_chip_config(): keep controller in init mode until bittiming is configured
can: softing: fw_parse(): validate firmware record spans
can: rcar_canfd: change the initializing flow for clocks and resets
can: kvaser_usb_leaf: kvaser_usb_leaf_wait_cmd(): validate received command extents
can: kvaser_usb: kvaser_usb_hydra_get_busparams(): fix memory leak in kvaser_usb_hydra_get_busparams()
can: peak_usb: validate uCAN receive record lengths
can: peak_usb: peak_usb_start(): fix double free of transfer buffer on URB submit error
can: peak_usb: add bounds check for USB channel index
can: ctucanfd: add missing MODULE_DEVICE_TABLE()
can: ctucanfd: use self-test mode for PRESUME_ACK
can: ctucanfd: handle bus error interrupts
can: ctucanfd: mark error-active controller status valid
can: ctucanfd: unmap BAR0 using base address
can: isotp: check register_netdevice_notifier() error in module init
can: isotp: fix timer drain order, wakeup handling and tx_gen ordering
can: j1939: transport: j1939_session_fresh_new(): initialize receive buffer
can: j1939: use netdevice_tracker for j1939_{priv,session,ecu} tracking
====================
Link: https://patch.msgid.link/20260729102802.505168-1-mkl@pengutronix.de
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
While attaching a newly created meter attach_meter() function makes
the new meter visible to other CPUs but can still fail afterwards.
On failure, it detaches the meter back and returns an error.
However, this is an unexpected behavior for the ovs_meter_cmd_set()
that uses a plain kfree(meter) on attach failure without waiting for
RCU readers to stop using it, assuming it was never visible.
This is never a problem for ovs-vswitchd as it always creates meters
before creating any flows that use them. But the UAF can be triggered
with a custom application using uAPI:
BUG: KASAN: slab-use-after-free in ovs_meter_execute (net/openvswitch/meter.c:653)
Read of size 8 at addr ffff88810d152650 by task meter/2508
Call Trace:
ovs_meter_execute (net/openvswitch/meter.c:653)
do_execute_actions (net/openvswitch/actions.c:1407)
ovs_execute_actions (net/openvswitch/actions.c:1584)
ovs_packet_cmd_execute (net/openvswitch/datapath.c:703)
...
netlink_sendmsg (af_netlink.c:1900)
Allocated by task 2519:
__kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415)
ovs_meter_cmd_set (net/openvswitch/meter.c:422)
...
netlink_sendmsg (af_netlink.c:1900)
Freed by task 2519:
kfree (mm/slub.c:2705 mm/slub.c:6405 mm/slub.c:6720)
ovs_meter_cmd_set (net/openvswitch/meter.c:479)
...
netlink_sendmsg (af_netlink.c:1900)
Fix that by making sure attach_meter() doesn't make the meter visible
until all the checks are done and the function can't fail anymore.
This also makes sure the "hash" value is calculated after the potential
re-sizing of the table.
Reported by Trend Micro's Zero Day Initiative as ZDI-CAN-31642.
Fixes: c7c4c44c9a ("net: openvswitch: expand the meters supported number")
Cc: stable@vger.kernel.org
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Reviewed-by: Eelco Chaudron <echaudro@redhat.com>
Link: https://patch.msgid.link/20260727121022.198461-1-i.maximets@ovn.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
ksz9131 is configured for local loopback in a similar fashion as the
ksz9031, with a need for full-duplex operation, but with some extra
steps to take as specified in section 4.13.1 :
1. Configure the following registers:
- MMD 1C, Register 15 = EEEE
- MMD 1C, Register 16 = EEEE
- MMD 1C, Register 18 = EEEE
- MMD 1C, Register 1B = EEEE
These 4 registers are marked as "Reserved" in the register map.
When setting loopback up without configuring these 4 registers, the PHY
appears to shut its RXC down, which can trigger failures on MACs that
require it, such as stmmac.
The datasheet does not specify to which state the registers must be
reset when disabling loopback, so let's restore them to their measured
initial values.
This was discovered when trying to use stmmac selftests on imx8mp with a
ksz9131 connected in RGMII.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260728075222.956780-1-maxime.chevallier@bootlin.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
