[PATCH AUTOSEL 6.18] net/mlx5: Relax capability check for eswitch query paths
From: Sasha Levin
Date: Mon Aug 31 2026 - 12:48:03 EST
From: Moshe Shemesh <moshe@xxxxxxxxxx>
[ Upstream commit 8ca32460815f6876095be8798adcf5ab982e94de ]
Several eswitch functions that only query other functions' HCA
capabilities or read cached vport state are guarded by the
vhca_resource_manager capability. This capability is required for
set_hca_cap operations but query_hca_cap of other functions only
requires the vport_group_manager capability.
Relax the capability check from vhca_resource_manager to
vport_group_manager in the following query-only paths:
- mlx5_esw_vport_caps_get() - queries other function general caps
- esw_ipsec_vf_query_generic() - queries other function ipsec cap
- mlx5_devlink_port_fn_migratable_get() - reads cached vport state
- mlx5_devlink_port_fn_roce_get() - reads cached vport state
- mlx5_devlink_port_fn_max_io_eqs_get() - queries other function caps
- mlx5_esw_vport_enable/disable() - vhca_id map/unmap
Functions that perform also set_hca_cap (migratable_set, roce_set,
max_io_eqs_set, esw_ipsec_vf_set_generic, esw_ipsec_vf_set_bytype)
retain the vhca_resource_manager requirement.
Signed-off-by: Moshe Shemesh <moshe@xxxxxxxxxx>
Reviewed-by: Akiva Goldberger <agoldberger@xxxxxxxxxx>
Reviewed-by: Mark Bloch <mbloch@xxxxxxxxxx>
Signed-off-by: Tariq Toukan <tariqt@xxxxxxxxxx>
Link: https://patch.msgid.link/20260506133239.276237-2-tariqt@xxxxxxxxxx
Signed-off-by: Jakub Kicinski <kuba@xxxxxxxxxx>
Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>
---
LLM Generated explanations, may be completely bogus:
The `git log -S` search finished, but it wasn’t very informative: for
both `mlx5_devlink_port_fn_max_io_eqs_get` and
`esw_ipsec_vf_query_generic`, the only hits were merge commits (e.g.
`5d324e5159d9e`), not the commits that originally added those functions
or the wrong `vhca_resource_manager` checks.
That fits the shallow checkout — we still can’t pin down when the bug
was introduced. What we do know is unchanged: both code paths are
present in 6.18.43 with the incorrect guards, and the fix exists on
other branches but not on current HEAD. The **YES** backport
recommendation still stands.
.../net/ethernet/mellanox/mlx5/core/esw/ipsec.c | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/eswitch.c | 6 +++---
.../ethernet/mellanox/mlx5/core/eswitch_offloads.c | 14 ++++++++------
3 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/esw/ipsec.c b/drivers/net/ethernet/mellanox/mlx5/core/esw/ipsec.c
index da10e04777cf7..1dbafeddd4b2f 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/esw/ipsec.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/esw/ipsec.c
@@ -12,7 +12,7 @@ static int esw_ipsec_vf_query_generic(struct mlx5_core_dev *dev, u16 vport_num,
void *hca_cap, *query_cap;
int err;
- if (!MLX5_CAP_GEN(dev, vhca_resource_manager))
+ if (!MLX5_CAP_GEN(dev, vport_group_manager))
return -EOPNOTSUPP;
if (!mlx5_esw_ipsec_vf_offload_supported(dev)) {
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
index c38deabcb7b96..132592faaca60 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
@@ -799,7 +799,7 @@ static int mlx5_esw_vport_caps_get(struct mlx5_eswitch *esw, struct mlx5_vport *
void *hca_caps;
int err;
- if (!MLX5_CAP_GEN(esw->dev, vhca_resource_manager))
+ if (!MLX5_CAP_GEN(esw->dev, vport_group_manager))
return 0;
query_ctx = kzalloc(query_out_sz, GFP_KERNEL);
@@ -934,7 +934,7 @@ int mlx5_esw_vport_enable(struct mlx5_eswitch *esw, struct mlx5_vport *vport,
vport->info.trusted = true;
if (!mlx5_esw_is_manager_vport(esw, vport_num) &&
- MLX5_CAP_GEN(esw->dev, vhca_resource_manager)) {
+ MLX5_CAP_GEN(esw->dev, vport_group_manager)) {
ret = mlx5_esw_vport_vhca_id_map(esw, vport);
if (ret)
goto err_vhca_mapping;
@@ -978,7 +978,7 @@ void mlx5_esw_vport_disable(struct mlx5_eswitch *esw, struct mlx5_vport *vport)
arm_vport_context_events_cmd(esw->dev, vport_num, 0);
if (!mlx5_esw_is_manager_vport(esw, vport_num) &&
- MLX5_CAP_GEN(esw->dev, vhca_resource_manager))
+ MLX5_CAP_GEN(esw->dev, vport_group_manager))
mlx5_esw_vport_vhca_id_unmap(esw, vport);
if (vport->vport != MLX5_VPORT_PF &&
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
index 8be0961cb6c7e..7a1c9ff6766e8 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
@@ -4344,8 +4344,9 @@ int mlx5_devlink_port_fn_migratable_get(struct devlink_port *port, bool *is_enab
return -EOPNOTSUPP;
}
- if (!MLX5_CAP_GEN(esw->dev, vhca_resource_manager)) {
- NL_SET_ERR_MSG_MOD(extack, "Device doesn't support VHCA management");
+ if (!MLX5_CAP_GEN(esw->dev, vport_group_manager)) {
+ NL_SET_ERR_MSG_MOD(extack,
+ "Device doesn't support vport group management");
return -EOPNOTSUPP;
}
@@ -4420,8 +4421,9 @@ int mlx5_devlink_port_fn_roce_get(struct devlink_port *port, bool *is_enabled,
struct mlx5_eswitch *esw = mlx5_devlink_eswitch_nocheck_get(port->devlink);
struct mlx5_vport *vport = mlx5_devlink_port_vport_get(port);
- if (!MLX5_CAP_GEN(esw->dev, vhca_resource_manager)) {
- NL_SET_ERR_MSG_MOD(extack, "Device doesn't support VHCA management");
+ if (!MLX5_CAP_GEN(esw->dev, vport_group_manager)) {
+ NL_SET_ERR_MSG_MOD(extack,
+ "Device doesn't support vport group management");
return -EOPNOTSUPP;
}
@@ -4685,9 +4687,9 @@ mlx5_devlink_port_fn_max_io_eqs_get(struct devlink_port *port, u32 *max_io_eqs,
int err;
esw = mlx5_devlink_eswitch_nocheck_get(port->devlink);
- if (!MLX5_CAP_GEN(esw->dev, vhca_resource_manager)) {
+ if (!MLX5_CAP_GEN(esw->dev, vport_group_manager)) {
NL_SET_ERR_MSG_MOD(extack,
- "Device doesn't support VHCA management");
+ "Device doesn't support vport group management");
return -EOPNOTSUPP;
}
--
2.53.0