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>
The ipip fill_forward_path callback currently does not check for
configurations that cannot be offloaded to hardware:
- Collect metadata (flow-based) tunnels have no fixed destination
and rely on per-packet tunnel metadata, so the forward path
cannot be pre-computed.
- TOS inheritance (parms.iph.tos & 0x1) requires copying the outer
TOS from the inner packet at encapsulation time, which is not
known during forward path resolution.
Return -EOPNOTSUPP for both cases to fall back to the software
forwarding path.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://patch.msgid.link/20260725-ipip-fill-forward-path-fix-v1-1-bc69fd3127d5@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Sang-Heon Jeon says:
====================
net: remove conditional returns with no effect
This series removes conditional returns where both branches return
the same value, so the check has no effect. As suggested by Jakub, the
netdev patches of the treewide v1 series [1] are posted separately.
All patches are generated by the Coccinelle script, which you can
find in v1.
The patch grouping is unchanged from v1. If you would rather split,
merge or drop any of the patches, just let me know and I will address
it in the next version.
[1] https://lore.kernel.org/all/20260723184538.3888637-1-ekffu200098@gmail.com/
---
Sang-Heon Jeon (4):
dpll: zl3073x: remove conditional return with no effect
net: ethernet: remove conditional return with no effect
net: remove conditional return with no effect
net: intel: remove conditional return with no effect
drivers/dpll/zl3073x/dpll.c | 6 +-----
drivers/dpll/zl3073x/out.c | 8 ++------
drivers/net/ethernet/amazon/ena/ena_netdev.c | 6 +-----
drivers/net/ethernet/aquantia/atlantic/aq_macsec.c | 6 +-----
drivers/net/ethernet/freescale/dpaa2/dpaa2-switch.c | 6 +-----
drivers/net/ethernet/freescale/gianfar.c | 6 +-----
drivers/net/ethernet/intel/i40e/i40e_main.c | 8 +-------
drivers/net/ethernet/intel/igb/e1000_i210.c | 6 +-----
drivers/net/ethernet/intel/igc/igc_phy.c | 6 +-----
drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c | 7 +------
drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_init.c | 6 +-----
drivers/net/ethernet/renesas/rtsn.c | 7 +------
drivers/net/phy/microchip_t1.c | 6 +-----
drivers/net/pse-pd/tps23881.c | 6 +-----
14 files changed, 15 insertions(+), 75 deletions(-)
====================
Link: https://patch.msgid.link/20260725150852.859188-1-ekffu200098@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
When TX VLAN hardware offload is disabled, VLAN tags are embedded in
the packet payload (software VLAN). Previously, the driver failed to
set the WX_TX_FLAGS_SW_VLAN flag for these packets during transmission.
This missing flag caused the txgbe FDIR ATR logic to fall through to the
default hash calculation path. This resulted in asymmetric hash values
for Tx and Rx flows, preventing return packets from being steered to the
same queue as the transmit packets.
Fix this by detecting software VLANs via eth_type_vlan(skb->protocol)
and setting WX_TX_FLAGS_SW_VLAN. This ensures the ATR feature selects
the correct hashing algorithm to maintain Tx/Rx queue symmetry.
Fixes: b501d261a5 ("net: txgbe: add FDIR ATR support")
Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/0879DA38A8E32701+20260724074657.10773-1-jiawenwu@trustnetic.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Breno Leitao says:
====================
netpoll: finish untangling netconsole from netpoll
This is the final series moving the netconsole-specific functions out of
netpoll and into netconsole.
There is nothing else left except struct netpoll ->name and ->dev_mac
fields, which are netconsole-specific fields, but they are still in
netpoll structure (no other netpoll user uses these two fields).
netpoll is now left simpler and with a clearer role: an API that takes
an skb and transmits it. The device setup and the local/remote address
handling that only netconsole needs no longer sit in the generic netpoll
code, but in netconsole (which was the only user).
struct netpoll gets leaner too. The netconsole-only fields are gone, so
the other netpoll users (bonding, team, bridge, vlan, macvlan, dsa) no
longer carry fields they never touch. (except ->name and ->dev_mac)
Signed-off-by: Breno Leitao <leitao@debian.org>
====================
Link: https://patch.msgid.link/20260724-netconsole_move_more_final-v1-0-a5f7691db81c@debian.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
netpoll_wait_carrier() waits for the egress device carrier during
netconsole setup. Its only caller, netcons_netpoll_setup(), already
lives in netconsole. Move the function into drivers/net/netconsole.c,
drop EXPORT_SYMBOL_GPL() and remove the prototype from <linux/netpoll.h>.
Rename it to netcons_wait_carrier() for the netcons_ prefix. It now reads
the timeout through netpoll_get_carrier_timeout(), since carrier_timeout
stays in netpoll to keep the netpoll.carrier_timeout parameter.
Signed-off-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Gustavo Luiz Duarte <gustavold@gmail.com>
Link: https://patch.msgid.link/20260724-netconsole_move_more_final-v1-9-a5f7691db81c@debian.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
With netpoll_setup() and the packet-building path now living in
netconsole, local_ip, remote_ip and ipv6 in struct netpoll are read
and written only by netconsole. No other netpoll user touches them.
Move the three fields into netconsole_target and switch the packet
builders and setup helpers to take the target instead of the netpoll
handle. struct netpoll is left holding only the device-binding state
that the shared netpoll transport needs.
Signed-off-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Gustavo Luiz Duarte <gustavold@gmail.com>
Link: https://patch.msgid.link/20260724-netconsole_move_more_final-v1-8-a5f7691db81c@debian.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Temporarily export leaf functions that will be moved to netconsole.
The upcoming patch will move the setup function to netconsole, and
continue to call these leaf functions here in netpoll, then other
patches will move these exports functions to netconsole (and make them
statics).
In summary, these exports are temporary in order to make the patchset
digestible.
Signed-off-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Gustavo Luiz Duarte <gustavold@gmail.com>
Link: https://patch.msgid.link/20260724-netconsole_move_more_final-v1-2-a5f7691db81c@debian.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
