Mike Rapoport says:
====================
drivers/net/ethernet: replace __get_free_pages() with kmalloc()
This is a (small) part of larger work of replacing page allocator calls
with kmalloc.
My initial intention a few month ago was to remove ugly casts [1], but then
willy pointed out that Linus objected to something like this [2] and it
looks like more than a decade old technical debt.
Largely, anything that doesn't need struct page (or a memdesc in the
future) should just use kmalloc() or kvmalloc() to allocate memory.
kmalloc() guarantees alignment, physical contiguity and working
virt_to_phys() and beside nicer API that returns void * on alloc and
doesn't require to know the allocation size on free, kmalloc() provides
better debugging capabilities than page allocator.
Another thing is that touching these allocation sites gives the reviewers
opportunity to see if a PAGE_SIZE buffer is actually needed or maybe
another size is appropriate.
For larger allocations that don't need physically contiguous memory
kvmalloc() can be a better option that __get_free_pages() because under
memory pressure it's is easier to allocate several order-0 pages than a
physically contiguous chunk with the same number of pages.
And last, but not least, removing needless calls to page allocator should
help with memdesc (aka project folio) conversion. There will be way less
places to audit to see if the user was actually using struct page.
Also in git:
https://git.kernel.org/pub/scm/linux/kernel/git/rppt/linux.git gfp-to-kmalloc/drivers-net-ethernet
[1] https://lore.kernel.org/all/20251018093002.3660549-1-rppt@kernel.org/
[2] https://lore.kernel.org/all/CA+55aFwp4iy4rtX2gE2WjBGFL=NxMVnoFeHqYa2j1dYOMMGqxg@mail.gmail.com/
====================
Link: https://patch.msgid.link/20260701-b4-drivers-ethernet-v1-0-58776615db6e@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
efx_mcdi_init() allocates a logging buffer for MCDI firmware
communication diagnostics.
This buffer can be allocated with kmalloc() as there's nothing special
about it to go directly to the page allocator.
kmalloc() provides a better API that does not require ugly casts and
kfree() does not need to know the size of the freed object.
Performance difference between kmalloc() and __get_free_pages() is not
measurable as both allocators take an object/page from a per-CPU list for
fast path allocations.
For the slow path the performance is anyway determined by the amount of
reclaim involved rather than by what allocator is used.
Replace use of __get_free_page() with kmalloc() and free_page() with
kfree().
Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Reviewed-by: Edward Cree <ecree.xilinx@gmail.com>
Link: https://patch.msgid.link/20260701-b4-drivers-ethernet-v1-4-58776615db6e@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
efx_siena_mcdi_init() allocates a logging buffer for MCDI firmware
communication diagnostics.
This buffer can be allocated with kmalloc() as there's nothing special
about it to go directly to the page allocator.
kmalloc() provides a better API that does not require ugly casts and
kfree() does not need to know the size of the freed object.
Performance difference between kmalloc() and __get_free_pages() is not
measurable as both allocators take an object/page from a per-CPU list for
fast path allocations.
For the slow path the performance is anyway determined by the amount of
reclaim involved rather than by what allocator is used.
Replace use of __get_free_page() with kmalloc() and free_page() with
kfree().
Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Reviewed-by: Edward Cree <ecree.xilinx@gmail.com>
Link: https://patch.msgid.link/20260701-b4-drivers-ethernet-v1-3-58776615db6e@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
ice_gnss_read() uses get_zeroed_page() to allocate a staging buffer for
reading GNSS module data via I2C bus.
This buffer can be allocated with kmalloc() as there's nothing special
about it to go directly to the page allocator.
kmalloc() provides a better API that does not require ugly casts and
kfree() does not need to know the size of the freed object.
Performance difference between kmalloc() and __get_free_pages() is not
measurable as both allocators take an object/page from a per-CPU list for
fast path allocations.
For the slow path the performance is anyway determined by the amount of
reclaim involved rather than by what allocator is used.
Replace use of get_zeroed_page() with kzalloc() and free_page() with
kfree().
Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Link: https://patch.msgid.link/20260701-b4-drivers-ethernet-v1-2-58776615db6e@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
bnx2x_mcast_enqueue_cmd() allocates memory for mac filtering list using
__get_free_pages().
This memory can be allocated with kzalloc() as there's nothing special
about it to go directly to the page allocator.
kmalloc() provides a better API that does not require ugly casts and
kfree() does not need to know the size of the freed object.
Performance difference between kmalloc() and __get_free_pages() is not
measurable as both allocators take an object/page from a per-CPU list for
fast path allocations.
For the slow path the performance is anyway determined by the amount of
reclaim involved rather than by what allocator is used.
Replace use of __get_free_page() with kzalloc() and free_page() with
kfree().
Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Link: https://patch.msgid.link/20260701-b4-drivers-ethernet-v1-1-58776615db6e@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
rmnet_get_endpoint() is shared by packet receive paths and
RTNL-protected control paths. The receive paths already run under RCU/BH
context through the RX handler, while the control paths reach
rmnet_get_endpoint() after obtaining the rmnet port with
rmnet_get_port_rtnl().
The helper walks port->muxed_ep[] with hlist_for_each_entry_rcu(). Pass
lockdep_rtnl_is_held() as the non-RCU protection condition so
CONFIG_PROVE_RCU_LIST can see the RTNL-protected control-path calls
while preserving the existing RCU-reader behavior for data paths.
This was found by our static analysis tool and then manually reviewed
against the current tree. The dynamic triage evidence is a
target-matched CONFIG_PROVE_RCU_LIST warning; the change is limited
to documenting the existing protection contract.
This is a lockdep annotation cleanup. It does not change endpoint
lifetime or hash updates.
Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
Reviewed-by: Subash Abhinov Kasiviswanathan <subash.a.kasiviswanathan@oss.qualcomm.com>
Link: https://patch.msgid.link/20260701124017.3205729-1-runyu.xiao@seu.edu.cn
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The GTP PDP lookup helpers are shared by RCU-protected data and report
paths and RTNL-protected control paths such as gtp_genl_new_pdp(). The
helpers walk RCU hlists, but they do not currently pass the RTNL
condition for the control-path lookups.
Pass lockdep_rtnl_is_held() to the PDP hlist iterators. Existing
RCU-reader callers remain valid because the RCU-list macros also accept
an active RCU read-side section; the added condition only documents the
non-RCU protection already used by RTNL control paths.
This was found by our static analysis tool and then manually reviewed
against the current tree. The dynamic triage evidence is a
target-matched CONFIG_PROVE_RCU_LIST warning; the change is limited
to documenting the existing protection contract.
This is a lockdep annotation cleanup. It does not change PDP lifetime or
hash updates.
Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260701123925.3193089-1-runyu.xiao@seu.edu.cn
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Add test_trunc exercising the OVS_ACTION_ATTR_TRUNC action. The test
verifies truncation limits in four steps: reject trunc(1) and
trunc(13) which are below ETH_HLEN, confirm normal forwarding works,
apply trunc(14) which truncates packets to the Ethernet header and
verify ping fails, then restore normal forwarding and verify recovery.
The kernel requires max_len >= ETH_HLEN (14 bytes). trunc(14) sets
OVS_CB(skb)->cutlen so pskb_trim strips the IP payload at output
time; the receiver drops the runt frame and no echo reply is
generated.
Signed-off-by: Minxi Hou <houminxi@gmail.com>
Reviewed-by: Aaron Conole <aconole@redhat.com>
Link: https://patch.msgid.link/20260702074926.1174810-1-houminxi@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Stanislav Fomichev says:
====================
net: hold instance lock around NETDEV_DOWN and NETDEV_GOING_DOWN
NETDEV_UP and NETDEV_REGISTER already run under the per-device
instance lock. The teardown side does not. Make it symmetric so
ops-locked drivers can rely on the lock being held in both
directions.
====================
Link: https://patch.msgid.link/20260702224150.3730033-1-sdf@fomichev.me
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The lock-state table marks UNREGISTER as unlocked without saying
why. Add a short note that many handlers release the lowers via
dev_close().
Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/20260702224150.3730033-7-sdf@fomichev.me
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Sprinkle a few asserts about ops lock: netif_close_many and __dev_notify_flags
should now consistently run under the lock
Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/20260702224150.3730033-6-sdf@fomichev.me
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
rtnl_configure_link calls __dev_change_flags() and __dev_notify_flags,
both need the instance lock. rtnl_newlink_create grabs it but stacked
devices do not. Move the lock inside rtnl_configure_link.
Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/20260702224150.3730033-5-sdf@fomichev.me
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
netif_close_many will soon assert ops lock (for locked DOWN/GOING_DOWN).
Update mtk_eth_set_dma_device to manually grab and release the ops lock.
Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/20260702224150.3730033-4-sdf@fomichev.me
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
netif_close_many will soon assert ops lock (for locked DOWN/GOING_DOWN).
Update dsa_switch_shutdown to manually grab and release the ops lock.
Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/20260702224150.3730033-3-sdf@fomichev.me
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Mirror what call_netdevice_register_net_notifiers does but for the
teardown. Cover only DOWN and GOING_DOWN. UNREGISTER is still unlocked
because of the SW devices using dev_xxx methods.
Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/20260702224150.3730033-2-sdf@fomichev.me
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE5DAy15EJMCV1R6v9YGjFFmlTOEoFAmpEQsUACgkQYGjFFmlT
OEpejQ/+OQ0+5tLHUP80eHPJDMx/WBlsGozmWF9LsTIkdZjd9WgVHTbQFMnny85Q
Fnzy1vBpXR7du4tAW+0TiDT7EsFqn1oxm3l5Ccpk2zP35SrPoGaWWSK9Sz6EXkrs
Ky90sJQw8WpggcZ4AnI1uXcsCtgvtMzdX7KHa51uox8g5JWFIAL5tVqCqhPSizlU
oL7iuvWETGLITw8VBu+TDm8fo/ZgrqzW7LE/GEyS+ZaDY3/OV+51DxMDqtNlLeE/
g3V9cGwiLEKhDo5UgVdBHUHcLLMOjJcWA6J90MlQ4Hc+SoIP35JN6lJ4zaXxfoEQ
GtOFRJNFs0m5uD5xDG2RpowPVnDuO73gLNwcxyI8G3uNVnNQKng03U0l34OMwnHv
aZa2FokgjreQ+3gKGKa7YD3d9VKw3TBoQL1bmU53vDMKuNHIedORdEGJgrwk5yLc
+AfFWKsSBUmYn3KdtnJqr8mxFDkzyD754OdIIVSra2fgkugb4pC8k0soEe2FI/9c
Q/ucYyyTUR/v+/9P5ZEV7GeOWzvcvRcuMwesarVsnSIXy40KYlDWjUBZ77t3/K9p
YmFe0/LX0bh1Z1KU0IxIUTWPFT74RCbgAhYK+e0AZ2NQB2loWkg/xsWbXj+ifmH4
iV9dK1qBTpIYoOs+Cd0dABqaR/RSIrbvtS7X0h8zyP22Eh/2xl4=
=PhAT
-----END PGP SIGNATURE-----
Merge tag 'sfc-net-pullrequest-20260630' of git://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl
Lucero Palau, Alejandro says:
====================
pull request: sfc 2026-07-01
here are the last CXL core changes for enabling CXL Type2 drivers to
initialize a CXL-capable device plus the netdev sfc driver changes using
this new CXL core Type2 support.
Please pull or let me know of any problem!
SFC changes for CXL type2 enabling
* tag 'sfc-net-pullrequest-20260630' of git://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl:
sfc: support pio mapping based on cxl
sfc: obtain and map cxl range using devm_cxl_probe_mem
sfc: Initialize cxl dpa
sfc: Map cxl regs
sfc: add cxl support
cxl: Support dpa without a mailbox
cxl: Support Type2 cxl regs mapping
====================
Link: https://patch.msgid.link/20260701113805.14072-1-alejandro.lucero-palau@amd.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
"queue_map" is a pointer to "u32" and is not modified by the
ppe_ring_queue_map_set() function, thus can be made a pointer to const to
indicate that function is treating the pointed value read-only. This in
general makes the code easier to follow and a bit safer.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Luo Jie <jie.luo@oss.qualcomm.com>
Link: https://patch.msgid.link/20260702094908.79859-4-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
There is no benefit in marking "const" a pass-by-value (not a pointer)
function argument, because it is passed as a copy on the stack. No code
readability improvements, no additional compiler-time safety for misuse.
Drop such redundant "const".
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Luo Jie <jie.luo@oss.qualcomm.com>
Link: https://patch.msgid.link/20260702094908.79859-3-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Tariq Toukan says:
====================
devlink and mlx5: Support cross-function rate scheduling
This series by Cosmin adds support for cross-function rate scheduling in
devlink and mlx5.
See detailed explanation by Cosmin below [0].
[0]
devlink objects support rate management for TX scheduling, which
involves maintaining a tree of rate nodes that corresponds to TX
schedulers in hardware. 'man devlink-rate' has the full details.
The tree of rate nodes is maintained per devlink object, protected by
the devlink lock.
There exists hardware capable of instantiating TX scheduling trees
spanning multiple functions of the same physical device (and thus
devlink objects) and therefore the current API and locking scheme is
insufficient.
This patch series changes the devlink rate implementation and API to
allow supporting such hardware and managing TX scheduling trees across
multiple functions of a physical device.
Modeling this requires having devlink rate nodes with parents in other
devlink objects. A naive approach that relies on the current
one-lock-per-devlink model is impossible, as it would require in some
cases acquiring multiple devlink locks in the correct order.
The solution proposed in this patch series makes use of the recently
introduced shared devlink instance [1] to manage rate hierarchy changes
across multiple functions.
V1 of this patch series was sent a long time ago [2], using a different
approach of storing rates in a shared rate domain with special locking
rules. This new approach uses standard devlink instances and nesting.
The first part of the series adds support to devlink rates for
maintaining the rate tree across multiple functions.
The second part changes the mlx5 implementation to make use of this (and
cleans up remnants of the previous approach, involving rate domains).
The neat part about using the shared devlink object is that it works for
SFs as well, which are already nested in their parent PF instances. So
with this series, complex scheduling trees spanning multiple SFs across
multiple PFs of the same NIC can now be supported.
====================
Link: https://patch.msgid.link/20260701073254.754518-1-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
It seems rates were not documented in the mlx5-specific file, so add
examples on how to limit VFs and groups and also provide an example of
the intended way to achieve cross-esw scheduling.
Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
Reviewed-by: Carolina Jubran <cjubran@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260701073254.754518-15-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Adds a Python selftest using the YNL devlink API to verify the devlink
rate ops. The test requires a bond device given in the config as NETIF
containing two PFs. Test setup will then create 1 VF on each PF and
verify the various rate commands.
./devlink_rate_cross_esw.py
TAP version 13
1..3
ok 1 devlink_rate_cross_esw.test_same_esw_parent
ok 2 devlink_rate_cross_esw.test_cross_esw_parent
ok 3 devlink_rate_cross_esw.test_tx_rates_on_cross_esw
Tests will be skipped when the preconditions aren't met, when the
devlink API is too old or when the devices don't appear to support
cross-esw scheduling (detected via EOPNOTSUPP).
Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
Reviewed-by: Carolina Jubran <cjubran@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260701073254.754518-14-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Up to now, rate groups could only contain vports from the same E-Switch.
This patch relaxes that restriction if the device supports it
(HCA_CAP.esw_cross_esw_sched == true) and the right conditions are met:
- Link Aggregation (LAG) is enabled.
- The E-Switches are from the same shared devlink device.
Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
Reviewed-by: Carolina Jubran <cjubran@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260701073254.754518-13-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
E-Switch QoS domains were added with the intention of eventually
implementing shared qos domains to support cross-esw scheduling in the
previous approach ([1]), but they are no longer necessary in the new
approach.
Remove QoS domains and switch to using the shd lock for protecting
against concurrent QoS modifications.
Enable the supported_cross_device_rate_nodes devlink ops attribute so
that all calls originating from devlink rate acquire the shd lock. Only
the additional entry points into QoS need to acquire the shd lock.
The wrinkle is that since shd can be NULL (e.g. on older HW without
serial number available), there needs to be a fallback locking
mechanism. The devlink instance lock cannot be used, as some code paths
into QoS (get, set & modify vport rate) happen with RTNL held, and the
existing devlink -> RTNL order prevents devlink lock usage there.
The other two options are either esw->state_lock or a new lock as
fallback when shd is NULL. This patch adds esw->state_lock, which
implies:
- 3 new lock/unlock helper pairs to acquire/release the missing lock:
- esw_qos_{,un}lock: acquire/release esw->state_lock when shd is NULL.
- esw_qos_shd_{,un}lock: when esw->state_lock is already held.
- esw_qos_devlink_{,un}lock: when shd is already held.
- esw_assert_qos_lock_held now asserts esw->state_lock is held when shd
is NULL.
Use the corresponding lock/unlock function in all places where either
shd or state_lock would need to be acquired.
Document all of this trickery next to esw_assert_qos_lock_held.
Enabling supported_cross_device_rate_nodes now is safe, because
mlx5_esw_qos_vport_update_parent rejects cross-esw parent updates.
This will change in the next patch.
[1]
https://lore.kernel.org/netdev/20250213180134.323929-1-tariqt@nvidia.com/
Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
Reviewed-by: Carolina Jubran <cjubran@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260701073254.754518-12-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
In commit [1] the concept of the root node in the qos hierarchy was
removed due to a bug with how tx_share worked. The side effect is that
in many places, there are now corner cases related to parent handling.
However, since that change, support for tc_bw was added and now, with
upcoming cross-esw support, the code is about to become even more
complicated, increasing the number of such corner cases.
Bring back the concept of the root node, to which all esw vports and
nodes are connected to. This benefits multiple operations which can
assume there's always a valid parent and don't have to do ternary
gymnastics to determine the correct esw to talk to.
As side effect, there's no longer a need to store the groups in the
qos domain, since normalization can simply iterate over all children of
the root node. Normalization gets simplified as a result.
There should be no functionality changes as a result of this change.
[1] commit 330f0f6713 ("net/mlx5: Remove default QoS group and attach
vports directly to root TSAR")
Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
Reviewed-by: Carolina Jubran <cjubran@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260701073254.754518-11-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Qos cleanup is a complex affair, because of the two modes of operation
(legacy and switchdev).
Leaf QoS is removed:
1. In legacy mode by esw_vport_cleanup() -> mlx5_esw_qos_vport_disable()
2. In switchdev mode by mlx5_esw_offloads_devlink_port_unregister() ->
mlx5_esw_qos_vport_update_parent(). A little later in the same flow, the
calls in 1 happen but they are noops.
Zooming out a bit, from both mlx5_eswitch_disable_locked() and
mlx5_eswitch_disable_sriov() the leaves are destroyed before the nodes,
which is the reverse of what should be.
For SFs there's no devl_rate_nodes_destroy() call to unparent the
affected leaf.
Sanitize all of this by:
1. Destroying nodes before leaves in both legacy and switchdev mode.
2. Only removing vport qos from esw_vport_cleanup(), reachable from both
legacy and switchdev and also reachable by SF removal.
3. Unexpose mlx5_esw_qos_vport_update_parent(), which becomes internal
to qos.
4. Remove the WARN in mlx5_esw_qos_vport_disable().
This also takes care of a theoretical corner case, when
mlx5_esw_qos_vport_update_parent() tried to reattach the vport to
the original parent on failure, which can fail as well, leaving the
vport in a broken state.
Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
Reviewed-by: Carolina Jubran <cjubran@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260701073254.754518-10-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Previously, the master device of the uplink netdev was queried for its
maximum link speed from the QoS layer, requiring the uplink_netdev mutex
and possibly the RTNL (if the call originated from the TC matchall
layer).
Acquiring these locks here is risky, as lock cycles could form. The
locking for the QoS layer is about to change, so to avoid issues,
replace the code querying the LAG's max link speed with the existing
infrastructure added in commit [1].
This simplifies this part and avoids potential lock cycles.
One caveat is that there's a new edge case, when the bond device is not
fully formed to represent the LAG device, the speed isn't calculated and
is left at 0. This now handled explicitly.
[1] commit f0b2fde980 ("net/mlx5: Add support for querying bond
speed")
Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
Reviewed-by: Carolina Jubran <cjubran@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260701073254.754518-9-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
This commit makes use of the building blocks previously added to
implement cross-device rate nodes.
A new 'supported_cross_device_rate_nodes' bool is added to devlink_ops
which lets drivers advertise support for cross-device rate objects.
If enabled and if there is a common shared devlink instance, then:
- all rate objects will be stored in the top-most common nested instance
and
- rate objects can have parents from other devices sharing the same
common instance.
Storing rates in the common shared ancestor is safe, because it is
reference counted by its nested devlink instances, so it's guaranteed to
outlive them. Furthermore, the shared devlink infra guarantees a given
nested devlink hierarchy is managed by the same driver.
The parent devlink from info->ctx is not locked, so none of its mutable
fields can be used. But parent setting only requires comparing devlink
pointer comparisons. Additionally, since the shared devlink is locked,
other rate operations cannot concurrently happen.
Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
Reviewed-by: Carolina Jubran <cjubran@nvidia.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260701073254.754518-8-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Currently, a devlink rate's parent device is assumed to be the same as
the one where the devlink rate is created.
This patch changes that to allow rate commands to accept an additional
argument that specifies the parent dev. This will allow devlink rate
groups with leafs from other devices.
Example of the new usage with ynl:
Creating a group on pci/0000:08:00.1 with a parent to an already
existing pci/0000:08:00.1/group1:
./tools/net/ynl/pyynl/cli.py --spec \
Documentation/netlink/specs/devlink.yaml --do rate-new --json '{
"bus-name": "pci",
"dev-name": "0000:08:00.1",
"rate-node-name": "group2",
"rate-parent-node-name": "group1",
"parent-dev": {
"bus-name": "pci",
"dev-name": "0000:08:00.1"
}
}'
Setting the parent of leaf node pci/0000:08:00.1/65537 to
pci/0000:08:00.0/group1:
./tools/net/ynl/pyynl/cli.py --spec \
Documentation/netlink/specs/devlink.yaml --do rate-set --json '{
"bus-name": "pci",
"dev-name": "0000:08:00.1",
"port-index": 65537,
"parent-dev": {
"bus-name": "pci",
"dev-name": "0000:08:00.0"
},
"rate-parent-node-name": "group1"
}'
Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
Reviewed-by: Carolina Jubran <cjubran@nvidia.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260701073254.754518-7-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Upcoming changes to the rate commands need the parent devlink specified.
This change adds a nested 'parent-dev' attribute to the API and helpers
to obtain and put a reference to the parent devlink instance in
info->ctx.
To avoid deadlocks, the parent devlink is unlocked before obtaining the
main devlink instance that is the target of the request.
A reference to the parent is kept until the end of the request to avoid
it suddenly disappearing.
This means that this reference is of limited use without additional
protection.
Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
Reviewed-by: Carolina Jubran <cjubran@nvidia.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260701073254.754518-6-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Devlink rate leafs and nodes were stored in their respective devlink
objects pointed to by devlink_rate->devlink.
This patch removes that association by introducing the concept of
'rate node devlink', which is where all rates that could link to each
other are stored. For now this is the same as devlink_rate->devlink.
After this patch, the devlink rates stored in this devlink instance
could potentially be from multiple other devlink instances. So all rate
node manipulation code was updated to:
- correctly compare the actual devlink object during iteration.
- maybe acquire additional locks (noop for now).
Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
Reviewed-by: Carolina Jubran <cjubran@nvidia.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260701073254.754518-5-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Replace deprecated info->user_ptr[0]/[1] with a typed
devlink_nl_ctx struct stored in info->ctx. The struct aliases
the same union memory, so the migration is safe.
There are no functionality changes here.
Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260701073254.754518-4-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Upcoming code will need to obtain references to locked nested-in
devlink instances. Add a helper to lock, reference and return the
nested-in instance.
Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
Reviewed-by: Carolina Jubran <cjubran@nvidia.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260701073254.754518-3-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
In commit [1] a comment about nested instance locking was updated. But
there's another place where this is mentioned, so update that as well.
[1] commit 0061b5199d ("devlink: Reverse locking order for nested
instances")
Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
Reviewed-by: Carolina Jubran <cjubran@nvidia.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260701073254.754518-2-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
When CONFIG_IP_MULTIPLE_TABLES is disabled, fib_new_table()
is fib_get_table(), and no new table is created.
Let's move net->ipv4.fib_table_hash_lock under
CONFIG_IP_MULTIPLE_TABLES.
While at it, netns_ipv4_sysctl.rst is updated.
Suggested-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260702044437.591864-2-kuniyu@google.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Ivan Vecera says:
====================
dpll: add NCO pin type and zl3073x support
Add a new DPLL_PIN_TYPE_INT_NCO pin type for virtual pins representing
the NCO mode of a DPLL and implement support for it in the zl3073x driver.
Patch 1 adds a STATE_CONNECTED_OVERRIDE pin capability for pins that
can override input selection in any DPLL mode, with a WARN_ON check
in dpll_pin_register() that STATE_CAN_CHANGE is also set.
Patch 2 adds the new INT_NCO pin type to the DPLL netlink spec and
UAPI header.
Patch 3 replaces the single 2s poll timeout with per-operation timeouts
based on Microchip proprietary source code and own measurement.
Patch 4 adds a per-DPLL serialization mutex taken by all DPLL callbacks
and the periodic worker, establishing a single lock that protects all
per-channel state. The chan_state_update() call is moved under this lock.
Patch 5 adds a virtual NCO input pin to the zl3073x driver that allows
userspace to switch a DPLL channel into NCO mode. The pin reports
connected/active state when the channel is in NCO mode and handles
the hardware-specific details of mode transitions including automatic
df_offset capture and 1PPS phase preservation.
Link: https://lore.kernel.org/netdev/20260531194423.383366-1-ivecera@redhat.com/
====================
Link: https://patch.msgid.link/20260630125536.720717-1-ivecera@redhat.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Add a virtual NCO (Numerically Controlled Oscillator) input pin that
lets userspace switch a DPLL channel into NCO mode. A single NCO pin
is shared across all DPLL channels - each channel has its own
independent connection state. The NCO pin is registered with the new
DPLL_PIN_TYPE_INT_NCO type and reports DPLL_PIN_STATE_CONNECTED /
DPLL_PIN_OPERSTATE_ACTIVE when the channel is in NCO mode.
At NCO pin registration the following bits are configured in
dpll_ctrl_x:
- nco_auto_read: auto-capture tracking offset on NCO entry
- tod_step_reset: apply negated ToD step accumulator on NCO exit
- tie_clear: PPS DPLLs set 1 to re-align outputs on NCO exit,
EEC DPLLs keep 0 to prevent an unwanted TIE write
Before switching to NCO mode, dpll_df_read_x is configured with
ref_ofst=0 and cmd=ACC_I so that nco_auto_read captures the
accumulated I-part offset relative to the master clock. Without
this, the captured df_offset would be near zero (offset relative
to the input reference after lock).
On NCO entry the df_offset captured by nco_auto_read is read from
the register. Per the datasheet, nco_auto_read only captures a valid
offset when entering NCO from reflock, auto or holdover mode; from
freerun the captured value is not meaningful and df_offset is marked as
ZL_DPLL_DF_OFFSET_UNKNOWN. The same sentinel is set in
chan_state_update() when the channel is not locked, and both FFO
consumers (NCO pin and input pin) guard against it.
Disconnecting the NCO pin switches to freerun rather than holdover
because holdover averaging is not updated during NCO mode.
When connecting the NCO pin displaces a previously connected input
pin (reflock mode), a change notification is sent for that input pin.
Input reference pins are now always registered regardless of the
initial DPLL mode. Previously they were skipped when the DPLL was
in NCO mode, but the NCO pin provides the proper mechanism for
mode transitions.
Reviewed-by: Petr Oros <poros@redhat.com>
Tested-by: Chris du Quesnay <Chris.duQuesnay@microchip.com>
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Link: https://patch.msgid.link/20260630125536.720717-6-ivecera@redhat.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Add a per-DPLL mutex that serializes all operations on a given DPLL
channel across DPLL netlink callbacks, the periodic kthread worker,
and (in subsequent patches) PTP clock callbacks.
All DPLL pin and device callbacks that access mutable state take the
lock as the first operation. The periodic worker holds it for the
entire check cycle of each channel, deferring change notifications
until after the lock is released to avoid ABBA deadlock with
dpll_lock. This establishes the lock ordering:
dpll_lock (subsystem, outer) -> zldpll->lock (driver, inner).
Move zl3073x_chan_state_update() from the per-device
zl3073x_dev_chan_states_update() loop into the per-DPLL
zl3073x_dpll_changes_check() so it runs under zldpll->lock.
This serializes df_offset writes with all readers and
eliminates the need for separate df_offset synchronization.
Change pin->freq_offset from atomic64_t to plain s64 since all
readers and writers are now serialized by zldpll->lock, making
atomic access unnecessary.
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Reviewed-by: Petr Oros <poros@redhat.com>
Link: https://patch.msgid.link/20260630125536.720717-5-ivecera@redhat.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Replace the single 2s timeout in zl3073x_poll_zero_u8() with a
per-caller timeout parameter. Different HW operations have different
expected completion times so using per-operation timeouts improves
error detection. The timeout values are based on proprietary source
code provided by Microchip and own measurement.
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Reviewed-by: Petr Oros <poros@redhat.com>
Link: https://patch.msgid.link/20260630125536.720717-4-ivecera@redhat.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Add DPLL_PIN_TYPE_INT_NCO pin type for virtual pins representing
the NCO mode of a DPLL. When connected as a DPLL input, the DPLL
enters NCO mode where the output frequency is adjusted by the host
via the PTP clock interface.
Update the fractional-frequency-offset and fractional-frequency-
offset-ppt attribute documentation to note that for INT_NCO pins
these attributes represent the DPLL's current output frequency
offset from its nominal frequency.
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Link: https://patch.msgid.link/20260630125536.720717-3-ivecera@redhat.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Add DPLL_PIN_CAPABILITIES_STATE_CONNECTED_OVERRIDE capability flag
that indicates a pin can be set to connected regardless of the
current DPLL device mode, overriding the active input selection.
This is useful for automatic-only DPLL devices where mode cannot
be switched to manual, allowing userspace to directly connect
such pin from automatic mode.
The capability requires STATE_CAN_CHANGE to be set as well;
dpll_pin_register() warns if a driver violates this.
Document the new capability in the Pin selection section of
Documentation/driver-api/dpll.rst.
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Link: https://patch.msgid.link/20260630125536.720717-2-ivecera@redhat.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Add test cases to reproduce scenarios fixed recently [1] where
multiqueue and taprio forced their children into enqueueing an skb to
gso_skb (during peek), but failed to dequeue from gso_skb because they
called the child's dequeue callback directly. This causes a desync in the
child's qlen/backlog and results in an eventual null-ptr-deref (with a
qfq or dualpi2 child).
Test cases are the following:
- Force multiq to dequeue from its child's gso_skb with qfq leaf (fb6c)
- Force multiq to dequeue from its child's gso_skb with dualpi2 leaf (1922)
- Force taprio to dequeue from its child's gso_skb with qfq leaf (476f)
- Force taprio to dequeue from its child's gso_skb with dualpi2 leaf (0235)
[1] https://lore.kernel.org/netdev/20260625-b4-disp-31bcb279-v1-0-85c40b83c529@proton.me/
Signed-off-by: Victor Nogueira <victor@mojatatu.com>
Reviewed-by: Pedro Tammela <pctammela@mojatatu.com>
Link: https://patch.msgid.link/20260630153651.249752-1-victor@mojatatu.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Update amt_fill_info() to run under RCU read lock instead of RTNL.
The AMT device configuration fields (mode, relay_port, gw_port, local_ip,
discovery_ip, max_tunnels) and stream_dev pointer are initialized during
device creation (amt_newlink) and are immutable. Accessing them locklessly
is safe. The stream_dev net_device structure is protected from being freed
by RCU.
The only field that can change concurrently is amt->remote_ip, which is
updated in the packet receive path (amt_advertisement_handler) and
workqueue (amt_req_work). Add READ_ONCE()/WRITE_ONCE() annotations
around amt->remote_ip to prevent data races.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260701125016.3650708-1-edumazet@google.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Add ethtool support to query and configure the PFC (Priority Flow Control)
storm prevention timeout. When TX continuously sends PFC frames, the peer
end is suppressed from sending packets. If this persists, a PFC frame storm
may occur.
This feature allows configuring a timeout to prevent such storms.
Signed-off-by: Hao Chen <chenhao418@huawei.com>
Signed-off-by: Jijie Shao <shaojijie@huawei.com>
Link: https://patch.msgid.link/20260630134043.1532431-1-shaojijie@huawei.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
-----BEGIN PGP SIGNATURE-----
iQJdBAABCABHFiEEgKkgxbID4Gn1hq6fcJGo2a1f9gAFAmpGOrIbFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMiwyDRxmd0BzdHJsZW4uZGUACgkQcJGo2a1f9gA+vQ//
eYDf4mJOdBusDUnc1FA4XXDtALhr3BNXs6EXckL4yUzK9SlYhZj7CfTxiyZlOW8U
emh4dOnIvuTLvEdr7OsY7jn+kUoN7jxuRzZ289mCj0JstlJsF4IEERAeKAHsQXTr
ro2pkovbsVKHx2aQGIIvQSN4y4Hv/nuAixGTDVTOOcTjDs2kh8DwvS2Tp4mKHwLO
4yITfrPqK349Kk5ojGr5I9rD/IThAxkg9WMgZD/me8rxnWg/g8ZVOYfOXrCGQwFL
SegIdWNWO3CFD1C1Ls6UYaxjCh8A+LmgbWGLRUbFELmaMzRWEZq2OmVGZuQu366s
lUc8uHTMTZwwBTD6e1/DadYOXPkbn9/Uz025KwQggvAcw5O8qqIf2Ow57ETr5CwN
2HqVp2zSwxcgW6OFD2iVElCjk6MMA9sIOa/Iz64bz1dEHuSzvOslMgrZuPtGrRrZ
aXp+VsF5OZuK2DiYCIgv1vK8Xr+vfeaztYMeMmcMawAbglHlShbWt6c9jMRTC2Qt
yj31wWIxFB4qlA9mAc9XE4A89J7y/WgpQF2s7uHvZokvVi1dsz5YQqJqRCo0732G
GmsB7+8oduldllokezsTKBCS5tUxiuN3YqYI3+7O+5+6JqVu2t7ZV7H1jvWgQePj
0RmOM5Jt6P2L/mdTKHIc5GcGUNCo63WzpaceNsgEA3U=
=yph7
-----END PGP SIGNATURE-----
Merge tag 'nf-next-26-07-02' of https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next
Florian Westphal says:
====================
netfilter: updates for net-next
The following patchset contains Netfilter updates for *net-next*.
1) Update nfnetlink_hook to dump the individual NAT type chains
instead of the nat base chains to userspace. From Phil Sutter.
2) Replace strlcpy/strlcat() with snprintf() in x_tables, from Ian Bridges.
3) Start replacing u_int8_t and u_int16t with u8 and u16 in netfilter.
From Carlos Grillet.
4) Replace strcpy() with strscpy() in netfilter, from David Laight.
5) Remove redundant NULL check before kvfree().
6) Add parameter validation to xt_tcpmss. Ensure mss_min <= mss_max and
invert <= 1. From Feng Wu.
7) Add checkentry for xt_dscp 'tos' match. Implement tos_mt_check() to reject
invalid invert values. Also from Feng Wu.
8) Stop hashing nf_conntrack_helper by tuple. Switch to hashing by name and
L4 protocol.
9) Remove tuples from conntrack helper definitions and port usage from
broadcast helpers. Add netlink policy validation to prevent protocol
number truncation.
10) Remove obsolete netfilter conntrack module parameters.
11) Bound num_counters in ebtables: do_replace() by MAX_EBT_ENTRIES to prevent
oversized vmalloc_array() allocations. From Jiayuan Chen.
12) Make expectations created via nft_ct rules work with NAT.
netfilter pull request nf-next-26-07-02
* tag 'nf-next-26-07-02' of https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next:
netfilter: nft_ct: support expectation creation for natted flows
netfilter: ebtables: bound num_counters like nentries in do_replace()
netfilter: conntrack: remove obsolete module parameters
netfilter: conntrack: get rid of tuple in helper definitions
netfilter: nf_conntrack_helper: do not hash by tuple
netfilter: xt_dscp: add checkentry for tos match
netfilter: xt_tcpmss: add checkentry for parameter validation
netfilter: remove redundant null check before kvfree()
netfilter: avoid strcpy usage
netfilter: replace u_int8_t and u_int16t with u8 and u16
netfilter: x_tables: replace strlcat() with snprintf()
netfilter: nfnetlink_hook: Dump nat type chains
====================
Link: https://patch.msgid.link/20260702105003.13550-1-fw@strlen.de
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Eric Dumazet says:
====================
macvlan: RTNL-less macvlan_fill_info()
This series removes the RTNL lock dependency from macvlan_fill_info(),
allowing it to run under RCU read lock.
The first patch annotates data races on 'mode' and 'flags' fields which
are accessed locklessly in the RX/TX paths.
The second patch transitions macvlan_fill_info() to RCU, adding necessary
annotations for other fields and handling concurrent updates to the MAC
address list by computing the count dynamically.
====================
Link: https://patch.msgid.link/20260701082214.2974946-1-edumazet@google.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Add READ_ONCE()/WRITE_ONCE() annotations on vlan->mode, vlan->flags,
vlan->bc_queue_len_req and port->bc_cutoff.
Fill IFLA_MACVLAN_MACADDR_DATA nested attribute and compute
on the fly the precise number of elements we put in it,
to fill an accurate IFLA_MACVLAN_MACADDR_COUNT attribute
as some user space applications could depend on its value
and the attributes order.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260701082214.2974946-3-edumazet@google.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Both fields can be changed in macvlan_changelink() while being read
locklessly.
Add READ_ONCE()/WRITE_ONCE() annotations.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260701082214.2974946-2-edumazet@google.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
