Correct spaces or mix of tabs+spaces into proper tab-indented lines.
No functional impact (same DTB).
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Harden the check for the constituent memory region page alignment
to prevent over-sharing when the negotiated FFA_PAGE_SIZE size is
smaller than the system PAGE_SIZE.
At the moment we only check that the size of the range is page
aligned, and truncate the address to the page boundary which can
annotate more memory than needed as being used by the FF-A.
Fixes: 4360900017 ("KVM: arm64: Handle FFA_MEM_SHARE calls from the host")
Signed-off-by: Mostafa Saleh <smostafa@google.com>
Reviewed-by: Vincent Donnefort <vdonnefort@google.com>
Signed-off-by: Sebastian Ene <sebastianene@google.com>
Link: https://patch.msgid.link/20260702103848.1647249-6-sebastianene@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
Prevent the pKVM hypervisor from making assumptions that the
endpoint memory access descriptor (EMAD) comes right after the
FF-A memory region header.
Prior to FF-A version 1.1 the header of the memory region
didn't contain an offset to the endpoint memory access descriptor.
The layout of a memory transaction looks like this from 1.1 onward:
Type | Field name | Offset
[ Header | ffa_mem_region | 0
EMAD 1 | ffa_mem_region_attributes) | ffa_mem_region.ep_mem_offset
]
Verify that the offset to the first endpoint memory access descriptor
is within the mailbox buffer bounds.
Also, fix one hardcoded sizeof(struct ffa_mem_region_attributes) that
should be replaced ffa_emad_size_get() for compatibility with FFA v1.0.
Fixes: 42fb33dde4 ("KVM: arm64: Use FF-A 1.1 with pKVM")
Signed-off-by: Mostafa Saleh <smostafa@google.com>
Signed-off-by: Sebastian Ene <sebastianene@google.com>
Reviewed-by: Vincent Donnefort <vdonnefort@google.com>
Link: https://patch.msgid.link/20260702103848.1647249-5-sebastianene@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
Sashiko (locally) reports out of bound write possiblity if SPMD
returns an invalid data.
While SPMD is considered trusted, pKVM does some basic checks,
for offset to be less than or equal len.
However, that is incorrect as even if the offset is smaller than
len pKVM can still access out of bound memory in the next
ffa_host_unshare_ranges().
Split this check into 2:
1- Check that the fixed portion of the descriptor fits.
2- After getting reg, check the variable array size addr_range_cnt
fits.
Also, drop the WARN_ONs as that will panic the kernel and in the
next checks there are no WARNs, so that makes it consistent.
Fixes: 0a9f15fd56 ("KVM: arm64: pkvm: Add support for fragmented FF-A descriptors")
Signed-off-by: Mostafa Saleh <smostafa@google.com>
Reviewed-by: Vincent Donnefort <vdonnefort@google.com>
Signed-off-by: Sebastian Ene <sebastianene@google.com>
Link: https://patch.msgid.link/20260702103848.1647249-4-sebastianene@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
This field is set to 'true' once and is never used again. Remove it to
eliminate dead code.
Signed-off-by: Nikolay Kulikov <nikolayof23@gmail.com>
Link: https://patch.msgid.link/20260531080015.74870-1-nikolayof23@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove tab characters that appeared after '/*' in two comment lines,
which caused 'please, no space before tabs' warnings. Replace the
space+tab combination with a single space after the comment opener.
Detected by checkpatch.pl with --strict flag.
Signed-off-by: Praveen Jayaprakash Pattar <praveen.pattar2022@gmail.com>
Link: https://patch.msgid.link/20260531045511.5774-1-praveen.pattar2022@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix incorrect indentation of an if statement inside an else block.
The statement had a space before it instead of proper tab alignment,
causing checkpatch.pl to report 'suspect code indent' and 'statements
should start on a tabstop' warnings.
Detected by checkpatch.pl with --strict flag.
Signed-off-by: Praveen Jayaprakash Pattar <praveen.pattar2022@gmail.com>
Link: https://patch.msgid.link/20260531040420.5426-1-praveen.pattar2022@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Correct spaces or mix of tabs+spaces into proper tab-indented lines and
remove other whitespace violations. No functional impact (same DTB).
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
The 'for' loop in ODM_TXPowerTrackingCallback_ThermalMeter performs no
operations and just iterates over the path count. This is unnecessary code.
Also, remove the associated "Print Swing base & current" comment, as
it no longer refers to any active code.
Signed-off-by: Igor Putko <igorpetindev@gmail.com>
Link: https://patch.msgid.link/20260525121004.4989-1-igorpetindev@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rename the variable 'nSubframe_Length' to 'subframe_len' in
amsdu_to_msdu() and rtw_alloc_msdu_pkt() to resolve a
checkpatch.pl CamelCase warning.
Signed-off-by: Anirban Bose <boses156@gmail.com>
Link: https://patch.msgid.link/20260525074419.144884-1-boses156@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix non-standard block comment format. The comment was using '/*++'
and '--*/' delimiters instead of the standard '/*' and '*/' used in
kernel coding style. Also fix missing '*' prefix on subsequent lines
and remove space before tab characters.
Detected by checkpatch.pl with --strict flag.
Signed-off-by: Praveen Jayaprakash Pattar <praveen.pattar2022@gmail.com>
Link: https://patch.msgid.link/20260524152506.5670-1-praveen.pattar2022@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove unnecessary braces around a single statement block
to improve readability and conform to kernel coding style.
No functional changes intended.
Signed-off-by: Atharv Margur <atharvmargur@gmail.com>
Link: https://patch.msgid.link/20260524111736.14477-1-atharvmargur@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When a device is destroyed under RTNL, ip_mc_destroy_dev() iterates through
the multicast list and calls ip_ma_put() on each membership, scheduling
them for RCU reclamation. However, they are not unlinked from the device's
multicast hash table (mc_hash).
Since the device remains published in dev->ip_ptr until after
ip_mc_destroy_dev() completes, concurrent RCU readers traversing mc_hash
can still locate and access the multicast group after its refcount is
decremented. If the RCU callback runs and frees the group while a reader is
accessing it, a use-after-free occurs.
Fix this by unlinking the multicast group from mc_hash using
ip_mc_hash_remove() before scheduling it for reclamation.
BUG: KASAN: slab-use-after-free in ip_check_mc_rcu+0x149/0x3f0
Read of size 4 at addr ffff888009bf1408 by task mausezahn/2276
Call Trace:
<IRQ>
dump_stack_lvl+0x67/0x90
print_report+0x175/0x7c0
kasan_report+0x147/0x180
ip_check_mc_rcu+0x149/0x3f0
udp_v4_early_demux+0x36d/0x12d0
ip_rcv_finish_core+0xb8b/0x1390
ip_rcv_finish+0x54/0x120
NF_HOOK+0x213/0x2b0
__netif_receive_skb+0x126/0x340
process_backlog+0x4f2/0xf00
__napi_poll+0x92/0x2c0
net_rx_action+0x583/0xc60
handle_softirqs+0x236/0x7f0
do_softirq+0x57/0x80
</IRQ>
Allocated by task 2239:
kasan_save_track+0x3e/0x80
__kasan_kmalloc+0x72/0x90
____ip_mc_inc_group+0x31a/0xa40
__ip_mc_join_group+0x334/0x3f0
do_ip_setsockopt+0x16fa/0x2010
ip_setsockopt+0x3f/0x90
do_sock_setsockopt+0x1ad/0x300
Freed by task 0:
kasan_save_track+0x3e/0x80
kasan_save_free_info+0x40/0x50
__kasan_slab_free+0x3a/0x60
__rcu_free_sheaf_prepare+0xd4/0x220
rcu_free_sheaf+0x36/0x190
rcu_core+0x8d9/0x12f0
handle_softirqs+0x236/0x7f0
Fixes: e989707135 ("igmp: hash a hash table to speedup ip_check_mc_rcu()")
Cc: stable@vger.kernel.org
Signed-off-by: Yuyang Huang <yuyanghuang@google.com>
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260701235014.73505-1-yuyanghuang@google.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Detected the following WARNING: function definition argument
'struct adapter *' should also have an identifier name.
Add explicit names on those definitions.
Signed-off-by: Rodrigo Gobbi <rodrigo.gobbi.7@gmail.com>
Link: https://patch.msgid.link/20260609221200.123422-1-rodrigo.gobbi.7@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix checkpatch warnings on inconsistent braces around if/else statements
in hal/sdio_halinit.c
Signed-off-by: Artur Ugnivenko <artur.ugnivenko@gmx.de>
Reviewed-by: Dan Carpenter <error27@gmail.com>
Link: https://patch.msgid.link/20260528170645.30861-3-artur.ugnivenko@gmx.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix checkpatch warnings on lines above 100 chars in length by splitting
long function calls and long comments into multiple lines.
Signed-off-by: Artur Ugnivenko <artur.ugnivenko@gmx.de>
Reviewed-by: Dan Carpenter <error27@gmail.com>
Link: https://patch.msgid.link/20260528170645.30861-2-artur.ugnivenko@gmx.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
padapter->HalData is allocated via vzalloc(), but incorrectly freed
using kfree() in the rtw_sdio_if1_init() error path. Using kfree() to
release this vmalloc-backed buffer can lead to memory corruption.
Use rtw_hal_data_deinit() to pair the free correctly and free
HalData with vfree().
The bug was first flagged by an experimental static analysis tool we
are developing for kernel memory-management bugs. Manual inspection
confirms that the issue is still present in current mainline.
An x86_64 allyesconfig build showed no new warnings. As we do not have
suitable RTL8723BS SDIO hardware to test with, no runtime testing was
able to be performed.
Fixes: 554c0a3abf ("staging: Add rtl8723bs sdio wifi driver")
Signed-off-by: Zilin Guan <zilin@seu.edu.cn>
Signed-off-by: Dawei Feng <dawei.feng@seu.edu.cn>
Reviewed-by: Dan Carpenter <error27@gmail.com>
Link: https://patch.msgid.link/20260525091836.812565-1-dawei.feng@seu.edu.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rename RxMgmtFrameSeqNum to rx_mgmt_frame_seq_num to comply with
kernel coding style.
Found by checkpatch.pl strict.
Signed-off-by: Gianmaria Biselli <gianmariabiselli@gmail.com>
Link: https://patch.msgid.link/20260524031212.26208-1-gianmariabiselli@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Adhere to the Linux kernel coding style by adding missing spaces
around the '*' binary operator in the init_channel_set function.
This resolves a checkpatch warning and improves code readability.
Signed-off-by: Mohammed Momin <linuxmomin0@gmail.com>
Link: https://patch.msgid.link/20260523171903.30484-1-linuxmomin0@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wrap the long function signature of rtw_os_xmit_resource_free to
comply with the 100 column line length limit reported by checkpatch.pl.
Signed-off-by: Pramod Maurya <pramod.nexgen@gmail.com>
Link: https://patch.msgid.link/20260523162831.163704-1-pramod.nexgen@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove unnecessary braces around single statement blocks
to improve readability and conform to kernel coding style.
No functional changes intended.
Signed-off-by: Atharv Margur <atharvmargur@gmail.com>
Link: https://patch.msgid.link/20260523141341.21607-1-atharvmargur@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Clean up the wlanevents table by removing redundant
ampersands, adding all index comments and aligning them.
Signed-off-by: Andrei Khomenkov <khomenkov@mailbox.org>
Link: https://patch.msgid.link/20260522190256.49830-3-khomenkov@mailbox.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove the dead rtw_atimdone_event_callback() function since it is
unused anywhere in the driver. In the wlanevents table, replace it
with rtw_dummy_event_callback() to avoid an index shift.
Signed-off-by: Andrei Khomenkov <khomenkov@mailbox.org>
Reviewed-by: Dan Carpenter <error27@gmail.com>
Link: https://patch.msgid.link/20260522190256.49830-2-khomenkov@mailbox.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reformat multi-line function signature to a single line to fix
line length and coding style warnings from checkpatch.pl.
Signed-off-by: Moksh Panicker <mokshpanicker.7@gmail.com>
Link: https://patch.msgid.link/20260522125022.29700-3-mokshpanicker.7@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rtl8192c_translate_rx_signal_stuff() and rtl8192c_query_rx_desc_status()
are declared in rtl8192c_recv.h but neither has a definition anywhere
in the driver, and there are no callers. Remove the dead declarations.
Signed-off-by: Pang-Chun Liu <kevin95120@gmail.com>
Reviewed-by: Dan Carpenter <error27@gmail.com>
Link: https://patch.msgid.link/20260521144113.28869-1-kevin95120@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Convert LPS_RF_ON_check() to return standard kernel error codes.
Replace -1 and -2 with -ETIMEDOUT and -ENODEV respectively.
No functional change intended as callers currently ignore
the return value.
Signed-off-by: Hungyu Lin <dennylin0707@gmail.com>
Link: https://patch.msgid.link/20260521104316.27739-3-dennylin0707@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Replace err + break pattern with direct returns to simplify
the control flow and improve readability.
No functional change intended.
Signed-off-by: Hungyu Lin <dennylin0707@gmail.com>
Link: https://patch.msgid.link/20260521104316.27739-2-dennylin0707@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
"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>
Right now dclk_vop2_src is not allowed to change its parent, while
the other two dclks are allowed to do this.
All three VPs can drive non-static outputs (HDMI, DP, eDP) and even the
eDP can also support full DP connections (though no DP+).
Therefore remove the CLK_SET_RATE_NO_REPARENT flag, to allow VP2 the same
flexibility in acquiring its clock rate.
Tested-by: Quentin Schulz <quentin.schulz@cherry.de> # RK3588 Tiger w/ DP
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
Reviewed-by: Quentin Schulz <quentin.schuz@cherry.de>
Tested-by: Chris Morgan <macromorgan@hotmail.com>
Link: https://patch.msgid.link/20260304121426.1184680-3-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
dclk_vop2_src currently has the CLK_SET_RATE_PARENT flag set, which is
very different from dclk_vop0_src or dclk_vop1_src, which don't have it.
With this flag in dclk_vop2_src, actually setting the clock then results
in a lot of other peripherals breaking, because setting the rate results
in the PLL source getting changed:
[ 14.898718] clk_core_set_rate_nolock: setting rate for dclk_vop2 to 152840000
[ 15.155017] clk_change_rate: setting rate for pll_gpll to 1680000000
[ clk adjusting every gpll user ]
This includes possibly the other vops, i2s, spdif and even the uarts.
Among other possible things, this breaks the uart console on a board
I use. Sometimes it recovers later on, but there will be a big block
of garbled output for a while at least.
Shared PLLs should not be changed by individual users, so drop this flag
from dclk_vop2_src.
Fixes: f1c506d152 ("clk: rockchip: add clock controller for the RK3588")
Cc: stable@vger.kernel.org
Tested-by: Quentin Schulz <quentin.schulz@cherry.de> # RK3588 Tiger w/ DP
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Tested-by: Chris Morgan <macromorgan@hotmail.com>
Link: https://patch.msgid.link/20260304121426.1184680-2-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
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>
