fjes_remove() destroys the driver workqueues before unregistering the
netdev. The interrupt handler queues work on them, but the IRQ is only
freed from fjes_close() under unregister_netdev(), so an interrupt in that
window can queue work once the workqueues are gone.
Unregister the netdev first so fjes_close() frees the IRQ and cancels the
workers before the workqueues are destroyed. force_close_task, which the
workers arm on the system workqueue, is handled in the next patch.
This issue was found by an in-house static analysis tool.
Cc: stable+noautosel@kernel.org # untested fix to a driver init path race
Signed-off-by: Fan Wu <fanwu01@zju.edu.cn>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260805011410.414431-1-fanwu01@zju.edu.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In cxacru_unbind(), cancel_delayed_work_sync() was conditionally skipped
when poll_state was CXPOLL_STOPPED. However, a work item previously
scheduled when poll_state was CXPOLL_POLLING may still be pending in the
workqueue at the time poll_state transitions to CXPOLL_STOPPED. Skipping
cancel_delayed_work_sync() in this case allows the work to fire after
cxacru_data is freed, causing a use-after-free when cxacru_poll_status()
attempts to acquire instance->poll_state_serialize.
Fix this by always calling cancel_delayed_work_sync() regardless of
poll_state, ensuring no pending or in-flight work can access the freed
instance.
Cc: stable+noautosel@kernel.org # untested fix to a driver init path race
Reported-by: syzbot+24eb38c789655fc43663@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=24eb38c789655fc43663
Signed-off-by: Nguyen Quang Le Kien <khiemtranzo532001@gmail.com>
Link: https://patch.msgid.link/20260803101716.2592486-1-khiemtranzo532001@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
If cxacru_cm() encounters an error while submitting or waiting for snd_urb,
it aborts and returns the error without killing the already submitted
rcv_urb. This leaves the rcv_urb active.
When this happens during initialization (e.g., in cxacru_atm_start()), the
driver may ignore the error and proceed to call cxacru_poll_status(), which
invokes cxacru_cm() again. Attempting to submit the still-active rcv_urb
triggers a warning in usb_submit_urb():
cxacru 1-1:1.0: send of cm 0x84 failed (-104)
ATM dev 0: cxacru_atm_start: CHIP_ADSL_LINE_START returned -104
------------[ cut here ]------------
URB ffff88812658d200 submitted while active
WARNING: drivers/usb/core/urb.c:379 at usb_submit_urb+0x79/0x18b0
drivers/usb/core/urb.c:379
...
Call Trace:
<TASK>
cxacru_cm+0x21a/0xf10 drivers/usb/atm/cxacru.c:631
cxacru_cm_get_array drivers/usb/atm/cxacru.c:722 [inline]
cxacru_poll_status+0x178/0x1110 drivers/usb/atm/cxacru.c:828
cxacru_atm_start+0x185/0x360 drivers/usb/atm/cxacru.c:814
usbatm_atm_init+0x144/0x3a0 drivers/usb/atm/usbatm.c:927
usbatm_usb_probe+0x15cb/0x1db0 drivers/usb/atm/usbatm.c:1178
cxacru_usb_probe+0x17f/0x220 drivers/usb/atm/cxacru.c:1370
...
To fix this, ensure that rcv_urb is properly killed if cxacru_cm() aborts
early. We can safely call usb_kill_urb() on rcv_urb in the error path, as
it is safe to call even if the URB is not active (e.g., if it failed to
submit in the first place, or if it already completed).
Cc: stable+noautosel@kernel.org # untested fix to unlikely driver error path
Reported-by: syzbot+c9dff578c3a41775176a@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=c9dff578c3a41775176a
Link: https://syzkaller.appspot.com/ai_job?id=75fec6f2-c8a6-43b1-b184-4d26baba86cc
Signed-off-by: Aleksandr Nogikh <nogikh@google.com>
Link: https://patch.msgid.link/91edfa4c-a63d-400c-9f00-31f3e1f98c00@mail.kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
struct macvlan_port is per lower device and is shared by every macvlan
upper on it, including uppers that live in other network namespaces.
Two of its fields are settable over rtnetlink by any upper on the port:
port->bc_cutoff, written by IFLA_MACVLAN_BC_CUTOFF, and
port->bc_queue_len_used, recomputed from IFLA_MACVLAN_BC_QUEUE_LEN.
(port->flags and port->perm_addr are also rtnetlink-settable, but only
in passthru mode, which requires port->count == 0 and so cannot be
reached from a second upper.)
rtnetlink checks CAP_NET_ADMIN against the network namespace the
configured device lives in and nothing else, so once a macvlan has been
moved into a child network namespace, an administrator of that namespace
alone reaches macvlan_changelink(), which applies both attributes
without considering who owns the lower device.
The create path has the same gap. macvlan_common_newlink() resolves a
lower device that is itself a macvlan to the real lower device:
if (netif_is_macvlan(lowerdev))
lowerdev = macvlan_dev_real_dev(lowerdev);
That real device may sit in a network namespace that was never
capability-checked. The new upper then joins its macvlan_port and runs
update_port_bc_queue_len() on it, and, when IFLA_MACVLAN_BC_CUTOFF is
present, update_port_bc_cutoff().
port->bc_cutoff is not a local tuning knob. update_port_bc_cutoff()
recomputes port->bc_filter, which macvlan_handle_frame() tests to decide
whether a multicast frame is deferred to the port broadcast work queue
or flooded inline from the RX softirq, and a negative cutoff clears
bc_filter outright. A namespace that administers none of the other
uppers can therefore change how all of them receive multicast.
Reproduced on 6.8 with a dummy lower device and two macvlan uppers, one
left in the initial namespace and one moved into a child user and
network namespace. From the child, both a changelink and a nested
newlink carrying IFLA_MACVLAN_BC_CUTOFF were accepted, and the value
read back on the initial-namespace sibling followed them, changing from
1 to -7 and then to -42.
Require CAP_NET_ADMIN in the lower device network namespace before
applying a shared port setting or creating a macvlan on a flattened
lower device. rtnl_dev_link_net_capable() short-circuits when the lower
device shares the macvlan network namespace, so an ordinary
single-namespace configuration is unaffected, and per-upper settings
such as mode and flags stay available to an administrator of the
macvlan's own namespace. This is the model ipvlan has used since
commit 7cc9f7003a ("ipvlan: disallow userns cap_net_admin to change
global mode/flags").
Found by 0sec automated security-research tooling (https://0sec.ai).
The newlink gate is unconditional rather than keyed on a BC attribute
being present, because joining another namespace's macvlan_port is
itself a mutation of shared state; ipvlan gates ipvlan_link_new() the
same way.
IFLA_MACVLAN_BC_QUEUE_LEN is gated here as well as by any magnitude
check, because the two address different things: a magnitude check
bounds how large a value any caller may request, while this bounds who
may write the shared port at all. update_port_bc_queue_len() takes the
maximum across uppers, so a cross-namespace lowering has no security
effect and this over-rejects it; that is accepted in exchange for one
rule covering every writer of the shared struct.
Cc: stable+noautosel@kernel.org # local DoS by userns are a dime a dozen
Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai>
Link: https://patch.msgid.link/20260802130137.98105-1-doruk@0sec.ai
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
ptp_clock_register() exposes the clock to userspace. If either following
initialization operation fails, probe returns and devres frees idtfc3 while
the registered clock still refers to the clock information embedded in it.
Complete the fallible initialization before registering the clock. Schedule
the worker after registration because it requires the registered clock.
This removes post-registration failures and avoids exposing a partially
initialized clock.
Cc: stable+noautosel@kernel.org # untested fix to a driver init path race
Co-developed-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
Link: https://patch.msgid.link/20260803135942.48383-1-mhun512@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Ilya Maximets says:
====================
openvswitch: remove support for legacy tunnel ports
ovs-vswitchd doesn't use OVS_VPORT_TYPE_GRE/VXLAN/GENEVE with the
Linux kernel module since adding support for standard tunnel devices
with COLLECT_METADATA back in 2017. The code to use them was only
activated as a fallback for old kernels, so not used in practice. And
it is now fully removed in the upcoming OVS 4.0 release.
Modern way to use tunnels with OVS is to create standard tunnel ports
with RTM_NEWLINK + COLLECT_METADATA and add them as OVS_VPORT_TYPE_NETDEV.
Device reference management and the netlink options parsing for these
legacy port types is complicated and was a CVE magnet in the previous
release cycles. Existence of these modules also makes locking analysis
for geneve module and other core tunnel devices unnecessarily more
complicated, especially in light of migration to per-netns locking:
https://lore.kernel.org/r/CAAVpQUDmZEaQNDSySLayqexgTrUbhBaL7XPCt9XNQzh+NGQ=UQ@mail.gmail.com
Since there are no actual users for these port types for a very long
time, let's just remove the support entirely. There is no practical
reason to run OVS from 2017 on a recent kernel.
While it's technically a uAPI change in some sense, from the user's
perspective this removal looks indistinguishable from the kernel built
with CONFIG_OPENVSWITCH_GENEVE/VXLAN/GRE disabled. And it seems like
removal of unused drivers/modules is not a rare event these days.
There are 3 parts to this set:
1. The first patch does the tunnel port removal, which is the primary
goal here.
2. Patches 2 and 3 remove extra infrastructure that is no longer in
use by anything inside the openvswitch module.
3. Patches 4-6 remove functions from gre/vxlan/geneve modules that
were added for openvswitch in the past to support the tunnel types.
openvswitch is the only in-tree consumer of these functions.
Version 1:
- Rebased.
- Removed the tunnel modules from the new OVS selftest config.
- Addressed RFC review from Sashiko:
* Made ovs_netdev_link() static.
* Restored -EOPNOTSUPP if OVS_VPORT_ATTR_OPTIONS was provided.
* Removed retry in ovs_vport_cmd_new() as not needed anymore.
RFC:
- https://lore.kernel.org/r/20260513183559.2141010-1-i.maximets@ovn.org
====================
Link: https://patch.msgid.link/20260804182049.2289754-1-i.maximets@ovn.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Since removal of legacy tunnel vport types only the built-in ones
remain. So, there is no need for the extra infrastructure for dynamic
module loading. Can be reinstated in the future if we need a new
vport type.
Note: It is technically possible that someone has an out-of-tree
module named vport-type-N that implements a different vport type.
At this time we're not aware of anyone doing that. People running
out-of-tree modules normally just have an out-of-tree openvswitch
module as a whole. And there are actually no supported out-of-tree
implementations of the openvswitch module known to the community.
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Link: https://patch.msgid.link/20260804182049.2289754-4-i.maximets@ovn.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Since removal of tunnel vport types, there aren't any vports that
support options. Let's remove the options-related infrastructure.
Can be reinstated if we ever need a new vport type or if we need extra
options for the existing ones. The uAPI attribute remains.
Clarification comment is added to highlight that none of the supported
vports support options at the moment.
If the options are provided, the code now directly replies with
-EOPNOTSUPP to keep the behavior the same for remaining vport types.
Note: It is technically possible that someone has an out-of-tree module
named vport-type-N that implements a different vport type and they have
options for this vport type. However, our message size calculations do
not account for whatever options such a port would have and so it is
dangerous to load such a module without modifying the code in the main
datapath.c, unless the options are smaller than the ones we had for
vxlan. A more robust solution would be to have a different version of
the entire openvswitch module instead, so the use case of a separate
vport-type-N loaded with the upstream openvswitch module is unlikely.
At this time we're not aware of anyone doing that.
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Link: https://patch.msgid.link/20260804182049.2289754-3-i.maximets@ovn.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
ovs-vswitchd doesn't use OVS_VPORT_TYPE_GRE/VXLAN/GENEVE with the
Linux kernel module since adding support for standard tunnel devices
with COLLECT_METADATA back in 2017. The code to use them was only
activated as a fallback for old kernels, so not used in practice. And
it is now fully removed in the upcoming OVS 4.0 release.
Modern way to use tunnels with OVS is to create standard tunnel ports
with RTM_NEWLINK + COLLECT_METADATA and add them as OVS_VPORT_TYPE_NETDEV.
Device reference management and the netlink options parsing for these
legacy port types is complicated and was a CVE magnet in the previous
release cycles. Existence of these modules also makes locking analysis
for geneve module and other core tunnel devices unnecessarily more
complicated, especially in light of migration to per-netns locking.
Since there are no actual users for these port types for a very long
time, let's just remove the support entirely. There is no practical
reason to run OVS from 2017 on a recent kernel.
While it's technically a uAPI change in some sense, from the user's
perspective this removal looks indistinguishable from the kernel built
with CONFIG_OPENVSWITCH_GENEVE/VXLAN/GRE disabled. And it seems like
removal of unused drivers/modules is not a rare event these days.
A comment is added to the uAPI header noting that standard RTM_NEWLINK
with COLLECT_METADATA followed by OVS_VPORT_CMD_NEW with the simple
OVS_VPORT_TYPE_NETDEV should be used instead.
Modules responsible for these tunnel ports are removed as well as
selftests covering this functionality. Further cleanups will follow.
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Link: https://patch.msgid.link/20260804182049.2289754-2-i.maximets@ovn.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
rtnl_fill_vf() emits one IFLA_VF_INFO per VF into the IFLA_VFINFO_LIST
nest and closes it with nla_nest_end(), which stores the accumulated
length into nla_len. That field is a u16, so a nest larger than 65535
bytes is written truncated modulo 65536. The list dates back to commit
c02db8c629 ("rtnetlink: make SR-IOV VF interface symmetric") in 2010
and has never been able to describe an arbitrary number of VFs; nothing
regressed, the encoding simply cannot represent it.
Nothing catches it on the way. if_nlmsg_size() adds rtnl_vfinfo_size()
for every VF, so the skb really is large enough and none of the nla_put()
calls fails. Userspace then walks the message with RTA_NEXT(), which
advances by the stored length, so parsing resumes inside VF payload and
the attributes after the nest are read out of VF data: IFLA_VF_PORTS,
IFLA_XDP, IFLA_LINKINFO, IFLA_PERM_ADDRESS, IFLA_AF_SPEC. iproute2
prints "!!!Deficit" and strictly validating parsers reject the message.
On CONFIG_DEBUG_NET kernels nla_nest_end() also splats, via the
DEBUG_NET_WARN_ON_ONCE() added in commit ff205bf8c5 ("netlink: add one
debug check in nla_nest_end()").
Where the wrap falls depends on what was asked for and on the host. A VF
costs 196 bytes, 296 with statistics, 236 with GUIDs and 336 with both,
and on a kernel without CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS the
statistics carry a padding attribute each and cost 32 bytes more, making
those two 328 and 368. The nest therefore overflows somewhere between 179
and 335 VFs, and ice allows 256 per PF (ICE_MAX_SRIOV_VFS), which reaches
it. Statistics are included unless the request sets
RTEXT_FILTER_SKIP_STATS, so the common case is the one that wraps first.
A limit that moves with the requested attribute set and with the host's
alignment requirements is not something userspace can be told, so use
fixed numbers instead and document them as what the interface supports:
256 VFs, or 128 when statistics are included. Both stay well inside
U16_MAX even in the largest per-VF encoding, at 60416 and 47104 bytes
respectively. rtnl_vfinfo_cap() applies the cap in both places, so
rtnl_vfinfo_size() does not size the skb for VFs that will not be
emitted.
A device with more VFs than the limit reports a shorter
IFLA_VFINFO_LIST. IFLA_NUM_VF keeps carrying the real count, and
everything after the nest stays parsable, which is the part that is
broken today. An empty nest is already emitted for a PF with no VFs, so a
list shorter than IFLA_NUM_VF is not a new encoding.
Returning -EMSGSIZE instead, which is what nla_nest_end_safe() would
give, is not an option here: a nest that does not fit in a u16 will not
fit in a retried skb either, so it would turn a link dump on such a
device into a hard failure.
The other large nests in rtnl_fill_ifinfo() were audited and cannot
overflow. IFLA_AF_SPEC is bounded by a handful of address families at
about a kilobyte each, and IFLA_VF_PORTS would need more than 560 VFs,
which no in-tree driver allows.
Reported-by: Jacob Keller <jacob.e.keller@intel.com>
Link: https://lore.kernel.org/netdev/16b289f6-b025-5dd3-443d-92d4c167e79c@intel.com/
Assisted-by: Claude:claude-fable-5
Signed-off-by: Artem Lytkin <iprintercanon@gmail.com>
Link: https://patch.msgid.link/20260801114944.115272-1-iprintercanon@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
AF_XDP rings are allocated from setsockopt() and can be mapped into user
space. The shared xskq_create() helper allocates the ring backing memory,
but the user-controlled and long-lived allocation is not charged as kmem
to the allocating memory cgroup.
The current implementation uses vmalloc_user(), which allocates the
backing pages with GFP_KERNEL | __GFP_ZERO. Use the same VM_USERMAP
vmalloc path, but pass GFP_KERNEL_ACCOUNT so the ring backing pages are
attributed to memcg/kmem and can be constrained by existing cgroup memory
limits. This keeps the existing zeroing and mmap semantics while avoiding
AF_XDP-specific optmem or RLIMIT_MEMLOCK accounting.
Signed-off-by: Zihan Xi <zihanx@nebusec.ai>
Acked-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/20260731164623.4694-2-zihanx@nebusec.ai
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The TX mitigation logic only sets the Interrupt on Completion bit once
every tx_coal_frames descriptors (STMMAC_TX_FRAMES = 25), with the
tx_coal_timer hrtimer (STMMAC_COAL_TX_TIMER = 5000 us) as the only
fallback. TX skbs are freed exclusively from the TX completion path,
so any flow that keeps fewer than 25 frames in flight has all of its
skbs held for up to 5 ms after transmission.
Paced flows never queue enough frames to reach the frame threshold:
TCP Small Queues caps the amount of unfreed data at roughly two pacing
intervals worth, which at moderate pacing rates is only a couple of
packets. Every small burst then stalls until the coalesce timer fires,
and throughput collapses to approximately tsq_limit / tx_coal_timer
regardless of link capacity.
This is easily reproducible with BBR, which paces its output and thus
keeps only a few frames in flight at a time. On a YT6801
(dwmac-motorcomm) equipped Orange Pi 5 Pro, a BBR upload over a ~23 ms
RTT path is capped at 5.24 Mbit/s, while CUBIC reaches 207 Mbit/s on
the same path. BBR measures the stalled send rate as the path
bandwidth and locks its estimate near the floor, so the connection
never recovers. Lowering the coalesce settings with ethtool -C
(tx-usecs 100 tx-frames 1) lifts the same transfer to 447 Mbit/s,
confirming the mechanism.
Fix this by setting the IC bit on the last descriptor of every xmit
burst, i.e. whenever netdev_xmit_more() reports that no further frames
are pending in the current dequeue batch. Frame-based coalescing still
applies within a burst, bulk traffic keeps batching through qdisc bulk
dequeue and NAPI polling, and the coalesce timer becomes a pure
fallback instead of the primary completion mechanism for lightly
queued flows.
tx-frames 0 keeps its meaning of timer-based mitigation only.
Signed-off-by: Johan Alvarado <contact@c127.dev>
Link: https://patch.msgid.link/20260731194522.55069-1-contact@c127.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Tariq Toukan says:
====================
net/mlx5: allocate doorbells from dma pools
This series by Nimrod extends the mlx5 internal DMA pool infrastructure
to doorbell objects.
Doorbell allocations currently use a separate pgdir allocator. Moving
them to the common mlx5 DMA pool implementation keeps the same coherent
DMA allocation model while sharing the pool code used by mlx5_frag_buf.
The series first creates per-node doorbell pools, then switches doorbell
allocation to use them, and finally exposes their usage through debugfs.
====================
Link: https://patch.msgid.link/20260803132520.2891860-1-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Allocate doorbells from dma pools instead of the pgdir allocator.
Doorbell records remain cache-line sized coherent DMA allocations, but
their sub-allocation is now handled by the common mlx5 DMA pool
infrastructure.
This also makes doorbell allocation honor the requested NUMA node when
reusing existing backing pages. The old pgdir allocator used the
requested node only when allocating a new pgdir page; later
allocations scanned one global pgdir list and could take any pgdir with
a free entry, even if that page had been allocated for a different
NUMA node. Selecting the per-node DMA pool before sub-allocation keeps
reused doorbell records on pages allocated for the requested node.
Signed-off-by: Nimrod Oren <noren@nvidia.com>
Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260803132520.2891860-3-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Vincent Jardin says:
====================
dpll: zl3073x: add Microchip ZL30643 support
The Microchip ZL30643 (chip ID 0x0E3B) is a 3 DPLL channel member of
the ZL3064x timing family, register compatible with the
ZL30733 of the ZL3073x family.
Patch 1 describes it in the binding as a fallback to the register-
equivalent microchip,zl30733.
Patch 2 adds the 0x0E3B runtime chip-ID table entry; no new match
strings, the fallback binds via the existing microchip,zl30733
entry.
====================
Link: https://patch.msgid.link/20260730-for-upstream-zl30643-v2-0-0ea0bbd03755@free.fr
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The Microchip ZL30643 is a 3-channel ZL3064x line-card part that is
register compatible with the ZL30733. Only the runtime chip-ID table
needs the 0x0E3B entry so the probe resolves the channel count (3)
and flags.
The ZL3073X_FLAG_REF_PHASE_COMP_32 flag applies unchanged: the
ref_phase path
dpll_meas_ctrl::en -> ref_phase_0P/0N
-> ref_phase_offset_compensation -> ref_phase_err_read_rqst
is identical between ZL3064x and ZL3073x. No new device flag is needed.
Test: once register, for instance, we get:
devlink dev param set spi/spi0.0 name clock_id value 3733 cmode driverinit
devlink dev reload spi/spi0.0
devlink dev param set spi/spi2.1 name clock_id value 3643 cmode driverinit
devlink dev reload spi/spi2.1
dpll device show | grep clock-id
clock-id: 3733
clock-id: 3733
clock-id: 3733
clock-id: 3643
clock-id: 3643
clock-id: 3643
Signed-off-by: Vincent Jardin <vjardin@free.fr>
Link: https://patch.msgid.link/20260730-for-upstream-zl30643-v2-2-0ea0bbd03755@free.fr
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The Microchip ZL30643 (chip ID 0x0E3B) is a member of the ZL3064x
line card timing family. It is register compatible with the 3-channel
ZL30733 (chip ID 0x0E95) of the ZL3073x family: both datasheets
describe the same register map and use the same chip-ID encoding.
Describe it with a fallback to microchip,zl30733 rather than a new
standalone compatible.
Signed-off-by: Vincent Jardin <vjardin@free.fr>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20260730-for-upstream-zl30643-v2-1-0ea0bbd03755@free.fr
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Junyang Han says:
====================
Add ZTE DingHai Ethernet PF driver
This series adds initial support for the ZTE DingHai Ethernet controller,
a high-performance PCIe Ethernet device supporting SR-IOV, hardware
offloading, and advanced virtualization features.
This is the initial submission and only includes the PF (Physical Function)
driver. The VF (Virtual Function) driver will be submitted separately.
====================
Link: https://patch.msgid.link/20260802160048653KdUvSUgDsEs4zwYF9Ey0q@zte.com.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Implement PCI configuration space access, BAR mapping, capability
scanning (common/notify/device), and hardware queue register
definitions for DingHai PF device.
Signed-off-by: Junyang Han <han.junyang@zte.com.cn>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
ptp_clock_adjtime() validates an ADJ_FREQUENCY request by converting the
requested scaled ppm to ppb and comparing it against ops->max_adj:
long ppb = scaled_ppm_to_ppb(tx->freq);
if (ppb > ops->max_adj || ppb < -ops->max_adj)
return -ERANGE;
scaled_ppm_to_ppb() computes (1 + ppm) * 125 >> 13 in s64. For a
sufficiently large tx->freq the multiplication overflows s64 and wraps,
so the resulting ppb can fall back within [-max_adj, max_adj] and pass
the check. The unclamped tx->freq is then handed to ->adjfine(), where
drivers scale it again (e.g. scaled_ppm * 762939453125 in ptp_idt82p33)
and program a bogus frequency word.
For example tx->freq = 147573952589676412 makes (1 + ppm) * 125 equal
2^64 + 9, which wraps to ppb == 0 and is accepted.
The caller already has write access to the PHC, so this hardens the
max_adj sanity check rather than crossing a privilege boundary, and
well-behaved user space (e.g. ptp4l) never requests such values. It is
a follow-up to commit 475b92f932 ("ptp: improve max_adj check against
unreasonable values"), which handled the analogous s32 narrowing but not
this multiplication overflow.
Detect the overflow with check_*_overflow() and reject the request in
ptp_clock_adjtime() instead of acting on the wrapped value.
Signed-off-by: Deep Shah <deepshah146@gmail.com>
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Acked-by: Richard Cochran <richardcochran@gmail.com>
Link: https://patch.msgid.link/20260801222923.39017-2-deepshah146@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
When a reviewer asks a developer to run an upstream test during code
review, it's often ambiguous whether the test was actually run against
a real device, or just against netdevsim. Print the driver name and
ifname at the start of the test, e.g.:
# Interface: enp0s13f0u1u4, driver: r8152
TAP version 13
1..1
ok 1 ...
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260803211944.2166211-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
On AMD Genoa/Turin platforms the BMC-provided USB-Ethernet gadget
(American Megatrends, VID 0x046b PID 0xffb0) intermittently fails to
respond to ARP after AC cold boot. usbmon captures a stale
NETWORK_CONNECTION(off) immediately followed by
NETWORK_CONNECTION(on) on the interrupt endpoint (~130us apart)
after enumeration. Because alloc_netdev() leaves
__LINK_STATE_NOCARRIER cleared, netif_carrier_ok() returns true
when the spurious OFF arrives, so usbnet_cdc_status() cannot
recognise it as redundant and schedules EVENT_LINK_CHANGE.
__handle_link_change() then calls unlink_urbs(), killing ~60 rx
URBs whose payload has already been DMA'd into memory — xHCI trace
confirms them completing as -ECONNRESET with non-zero residual
length. rx_complete() drops these unconditionally. The following
ON restores the carrier and re-submits URBs, but the ARP reply is
already lost; the interface looks "up but silent" until ifdown/ifup.
Fix this by adding a device-specific quirk with FLAG_LINK_INTR set,
which makes usbnet_probe() call netif_carrier_off() after bind.
With initial carrier == OFF, usbnet_cdc_status() recognises the
spurious OFF as matching the current state and drops it; the
subsequent ON is the first real event and brings the link up
cleanly without ever tearing down the rx queue. The scheduled
link-change kevent is harmless because EVENT_DEV_OPEN is not yet
set at probe time.
This is applied as a device-specific quirk rather than a change to
the shared cdc_info driver_info because some CDC devices never
send NETWORK_CONNECTION notifications; forcing carrier off for
them would leave the link permanently DOWN. Restricting the change
to this VID/PID keeps that class of device untouched.
Tested on Genoa and Turin across 100+ AC cold boot cycles; ping
first-packet success rate went from intermittent to 100%.
Signed-off-by: Jinhui Guo <guojinhui.liam@bytedance.com>
Link: https://patch.msgid.link/20260730051341.24930-1-guojinhui.liam@bytedance.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Nikhil P. Rao says:
====================
pds_core: Add PLDM firmware update and host backed memory support
This series adds PLDM-based firmware update support to the pds_core
driver. PLDM (Platform Level Data Model) is a DMTF standard for firmware
management that provides a vendor-neutral interface for firmware updates.
The implementation uses the kernel's pldmfw library for package parsing
and component matching. Users can update entire firmware packages or
individual components via devlink flash. Component information is
displayed via devlink info, showing firmware versions and update status
for each component.
The series also adds host backed memory support, allowing firmware to
request memory pages from the host for its operations.
====================
Link: https://patch.msgid.link/20260730-upstream_v8-v12-0-136cd174ee85@amd.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Some newer AMD/Pensando cards have minimal memory and there are cases
where components, specifically in the control plane, need more memory.
This series adds support for host backed DMA memory that can be used
by the firmware for the previously mentioned cases.
Host memory allocation is best-effort: if some allocations fail, the
driver continues with whatever succeeded. Firmware gracefully degrades
when less memory is available than requested.
Signed-off-by: Vamsi Atluri <Vamsi.Atluri@amd.com>
Signed-off-by: Nikhil P. Rao <nikhil.rao@amd.com>
Link: https://patch.msgid.link/20260730-upstream_v8-v12-5-136cd174ee85@amd.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add detailed component information display via devlink info. This
allows users to see individual firmware components and their versions.
Components are reported as fixed, running, or stored based on their
firmware-provided flags.
Example output:
$ devlink dev info pci/0000:00:05.0
versions:
fixed:
asic.id 0x0
asic.rev 0x0
running:
fw.bootloader 1.2.3
fw.uboot 1.60.0-73
fw 1.60.0-73
fw.cpld 3.18
stored:
fw.bootloader 1.2.3
fw.uboot 1.60.0-73
fw.uboot.gold 1.50.0-22
fw.gold 1.50.0-22
fw 1.60.0-73
fw.cpld 3.18
Signed-off-by: Brett Creeley <brett.creeley@amd.com>
Link: https://patch.msgid.link/20260730-upstream_v8-v12-4-136cd174ee85@amd.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Implement PLDM FW Update in the pds_core driver using the upstream
pldmfw API. This allows updating an entire PLDM FW package at once
or updating specific firmware components by name.
Flash the entire image:
devlink dev flash pci/0000:b5:00.0 file firmware.pldmfw
Flash a specific component from the PLDM FW package:
devlink dev flash pci/0000:b5:00.0 \
file firmware.pldmfw component fw.cpld
Per-component update uses driver-defined component names (fw, fw.cpld,
etc.). Not all components support per-component update - devlink will
reject the request if the specified component cannot be updated.
Signed-off-by: Brett Creeley <brett.creeley@amd.com>
Signed-off-by: Nikhil P. Rao <nikhil.rao@amd.com>
Link: https://patch.msgid.link/20260730-upstream_v8-v12-3-136cd174ee85@amd.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add a new capabilities field in struct pds_core_dev_identity,
which requires bumping the identity version to 2, i.e.
PDS_CORE_IDENTITY_VERSION_2. If version 2 negotiation fails,
then quietly fall back to version 1. If version 1 negotiation
fails, then driver load will fail.
Another patch in the series will make use of the capabilities
field.
Signed-off-by: Brett Creeley <brett.creeley@amd.com>
Link: https://patch.msgid.link/20260730-upstream_v8-v12-2-136cd174ee85@amd.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Currently there aren't any use-cases that require special handling
on whether or not to print devcmd failures. Specifically
non-generic failures, i.e. not supported failures. Add support to
allow these messages to be suppressed. This will be used when
adding support to negotiate PDS_CORE_IDENTITY_VERSION_2.
Signed-off-by: Brett Creeley <brett.creeley@amd.com>
Link: https://patch.msgid.link/20260730-upstream_v8-v12-1-136cd174ee85@amd.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
rds_info_getsockopt() reads a callback from rds_info_funcs and invokes it
without protecting the callback's lifetime. Transport modules register
functions stored in this array. For example, rds_tcp.ko registers
rds_tcp_tc_info() for RDS_INFO_TCP_SOCKETS.
This permits the following interleaving:
CPU0 CPU1
rds_info_getsockopt()
func = rds_tcp_tc_info
rmmod rds_tcp
rds_tcp_exit()
rds_info_deregister_func()
rds_info_funcs[offset] = NULL
free rds_tcp module text
func()
The reader can therefore branch to an address in unloaded module text.
Protect callback invocation with SRCU. Enter the SRCU read-side critical
section before loading the callback and leave it only after the callback
returns. Clear the callback with WRITE_ONCE() and call
synchronize_srcu() before deregistration returns, preventing module unload
from freeing its text while an old reader is still executing it. SRCU is
required because callbacks such as RDS_INFO_COUNTERS can sleep.
Keep the callback array unannotated and use READ_ONCE() and WRITE_ONCE()
for concurrent slot access so sparse does not have to apply __rcu through
the function-pointer typedef. Replace the two callback-slot BUG_ON()
checks with WARN_ON_ONCE() and return without changing the slot on
mismatch.
Link: https://lore.kernel.org/netdev/20260720184955.3008978-1-nicoyip.dev@gmail.com/
Suggested-by: Allison Henderson <achender@kernel.org>
Suggested-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Allison Henderson <achender@kernel.org>
Signed-off-by: Chengfeng Ye <nicoyip.dev@gmail.com>
Link: https://patch.msgid.link/20260801054234.3535077-1-nicoyip.dev@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
tja1102_p0_probe() schedules work to register the second port. That work
uses the Port 0 private data and phydev. The private data is
devm-allocated, but the driver does not wait for the pending work on
remove.
Store the Port 0 private data in phydev->priv and add a remove callback.
The callback cancels the registration work before devres teardown frees
the state.
This issue was found by a static analysis tool.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Hongyan Xu <getshell@seu.edu.cn>
Link: https://patch.msgid.link/20260801140643.1871-1-getshell@seu.edu.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
pfcp_net_exit_rtnl() iterates pfcp devices whose sockets
are in the dying netns and queues them for destruction.
So the devices may reside in different netns.
Let's use unregister_netdevice_queue_net() to support per-netns
device unregistration.
list_del() is changed to list_del_init() to avoid queueing the
same device twice.
Even after pfcp_net_exit_rtnl() queues a cross-netns pfcp device,
pfcp_dellink() could be called concurrently for it (once RTNL is
removed). In such a case, __rtnl_net_unlock() will perform the
unregistration.
We can see pfcp0 below is unregistered by the per-netns work
instead of cleanup_net().
# bpftrace -e '#include <linux/netdevice.h>
kprobe:pfcp_dev_uninit {
$dev = (struct net_device *)arg0;
printf("PID: %d | DEV: %s%s\n", pid, $dev->name, kstack());
}
kprobe:pfcp_net_exit_rtnl {
printf("PID: %d%s\n", pid, kstack());
}' &
# ip netns add ns1
# ip netns add ns2
# ip -n ns1 link add pfcp0 link-netns ns2 type pfcp
# ip netns del ns2
PID: 12
pfcp_net_exit_rtnl+5
ops_undo_list+702
cleanup_net+1122
process_scheduled_works+2538
...
PID: 462 | DEV: pfcp0
pfcp_dev_uninit+5
unregister_netdevice_many_notify+7129
unregister_netdevice_many_net+1050
rtnl_net_work_func+136
process_scheduled_works+2538
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260731224406.2444121-3-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
struct pfcp_dev.net is the netns where the backend pfcp socket
resides.
struct pfcp_dev is linked to the pfcp_net.pfcp_dev_list of
the socket's netns.
During netns dismantle or module unload, pfcp_net_exit_rtnl()
iterates the list and queues devices for destruction regardless
of the devices' netns.
Thus, once RTNL is removed, the list can be modified concurrently
from different netns due to device removal.
Let's protect it with per-netns mutex.
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260731224406.2444121-2-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
When a function-like macro expands to an expression, that expression
doesn't need a semicolon after it. All uses have been verified to
have their own semicolons.
This was found using the following Coccinelle semantic patch:
@r@
identifier i : script:ocaml() { String.lowercase_ascii i = i };
expression e;
@@
*#define i(...) e;
Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
Link: https://patch.msgid.link/20260801191002.1383835-10-Julia.Lawall@inria.fr
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
When a function-like macro expands to an expression, that expression
doesn't need a semicolon after it. All uses have been verified to
have their own semicolons.
This was found using the following Coccinelle semantic patch:
@r@
identifier i : script:ocaml() { String.lowercase_ascii i = i };
expression e;
@@
*#define i(...) e;
Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
Link: https://patch.msgid.link/20260801191002.1383835-5-Julia.Lawall@inria.fr
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
HDS mode has confusing semantics. On GET kernel reports
effective mode. On SET kernel expects explicit config.
Effective mode on GET means that we know the current
state, but we don't know if it's a driver default
or user setting. This matter because driver default
can change automatically when e.g. XDP is attached.
Explicit user setting must not be lost.
With that in mind, we can't restore the HDS setting
like we restore other NIC config. We should always
reset to default ("unknown").
This fixes an issue with tests running after the devmem
test not being able to attach XDP, e.g.
Exception| File "./xdp_metadata.py", line 105, in test_xdp_rss_hash
[...]
Exception| net.lib.py.utils.CmdExitFailure: Command failed
Exception| CMD: ip link set dev ens9np0 xdpdrv pinned /sys/fs/bpf/xdp_metadata_test/xdp_rss_hash
Exception| EXIT: 2
Exception| STDERR: Error: unable to install XDP to device using tcp-data-split.
not ok 1 xdp_metadata.test_xdp_rss_hash.tcp
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Bobby Eshleman <bobbyeshleman@meta.com>
Link: https://patch.msgid.link/20260804151040.2755153-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The external flag is part of the PCI SF port attributes, but unlike the
PCI PF and PCI VF flavours it was never filled into the port dump, so
userspace could not query it directly.
Reporting of the external flag was missed for SF ports. Hence, put
DEVLINK_ATTR_PORT_EXTERNAL for the PCI SF flavour as well, matching what
PCI PF and PCI VF ports already report.
$ devlink port show pci/0033:01:00.0/163840
pci/0033:01:00.0/163840: type eth netdev eth1 flavour pcisf controller 1 pfnum 0 sfnum 77 external true splittable false
Reviewed-by: Parav Pandit <parav@nvidia.com>
Signed-off-by: Shay Drory <shayd@nvidia.com>
Link: https://patch.msgid.link/20260803090012.257242-1-shayd@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Pablo Neira Ayuso says:
====================
Netfilter updates for net-next
The following patchset contains Netfilter updates for net-next:
1) Update conncount to use the original tuple after ct lookup to ensure
consistent counting, from Fernando F. Mancera.
2) Remove redundant net_device field in info structure that helps
parse the flowtable path discovery.
3) Move net_device to flowtable check to the flowtable discovery
path parser. This is preparation work to pass the tunnel dst_entry
via .fill_forward_path.
4) Update DSA .fill_forward_path to break at the user DSA, since
the conduit DSA is not used in the datapath. This slighly simplifies
the flowtable path discovery parser.
5) Do not advance index in the path stack prematurely, otherwise
it points to uninitialized slots on error. Not an issue currently
but it could be once tunnel dst_entry is passed via .fill_forward_path.
6) Pass the tunnel dst_entry via dev_fill_forward_path().
7) Update ipip and ip6ip6 tunnels to pass the dst_entry through
dev_fill_forward_path().
8) Call skb_valid_dst() before accessing skb_dst() to ensure dst_entry
is not a template.
9) Use UNACK timeout when RST packet does not match the expected
window while in ESTABLISHED state, the existing approach the CLOSE
state timeout which is only 10 seconds. Adopt a more conservative
timeout by default for this case.
* tag 'nf-next-26-07-31' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next:
netfilter: conntrack: tcp: use UNACK timeout for non-closing RST packets
netfilter: nf_tables: call skb_valid_dst() before skb_dst()
netfilter: flowtable: release tunnel route on error when building forward path
net: pass dst via net_device_path in dev_fill_forward_path()
net: do not advance stack index from dev_fwd_path()
net: dsa: stop at the user device in .fill_forward_path
netfilter: flowtable: consolidate flowtable device check
netfilter: flowtable: consolidate net_device field in nft_forward_info struct
netfilter: conncount: normalize tuple and zone on successful ct lookup
====================
Link: https://patch.msgid.link/20260731153402.851224-1-pablo@netfilter.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
