[PATCH net 0/2] net/mlx5: HWS, fix reformat release and meter offset

[PATCH net 0/2] net/mlx5: HWS, fix reformat release and meter offset

[Alexandre Cassen]

This series fixes two issues in fs_hws found while offloading one tc
rule with its own encap and meter:

- Releases L2 to L3 tunnel reformats to the pool they come from.
- Makes a rule select its flow meter within the whole ASO bulk.

Alexandre

Alexandre Cassen (2):
  net/mlx5: HWS, release L2 to L3 tunnel reformats to their own pool
  net/mlx5: HWS, fix flow meter offset within its bulk

 .../net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.c    | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

-- 
2.43.0

[PATCH net 1/2] net/mlx5: HWS, release L2 to L3 tunnel reformats to their own pool

[Alexandre Cassen]

L2 to L3 tunnel reformats are now released to the el2tol3tnl pools.

Fixes: aecd9d1020e3 ("net/mlx5: fs, add HWS packet reformat API function")
Signed-off-by: Alexandre Cassen <acassen@corp.free.fr>
---
 drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.c b/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.c
index 5a172c572a68..44b311b4532d 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.c
@@ -1398,8 +1398,8 @@ static void mlx5_cmd_hws_packet_reformat_dealloc(struct mlx5_flow_root_namespace
 						    pr_data->data_size);
 		break;
 	case MLX5_REFORMAT_TYPE_L2_TO_L3_TUNNEL:
-		pr_pool = mlx5_fs_get_pr_encap_pool(dev, &hws_pool->el2tol2tnl_pools,
-						    MLX5HWS_ACTION_TYP_REFORMAT_L2_TO_TNL_L2,
+		pr_pool = mlx5_fs_get_pr_encap_pool(dev, &hws_pool->el2tol3tnl_pools,
+						    MLX5HWS_ACTION_TYP_REFORMAT_L2_TO_TNL_L3,
 						    pr_data->data_size);
 		break;
 	case MLX5_REFORMAT_TYPE_L3_TUNNEL_TO_L2:
-- 
2.43.0

Re: [PATCH net 1/2] net/mlx5: HWS, release L2 to L3 tunnel reformats to their own pool

[Yevgeny Kliteynik]

On 07-Oct-26 17:38, Alexandre Cassen wrote:
> L2 to L3 tunnel reformats are now released to the el2tol3tnl pools.
> 
> Fixes: aecd9d1020e3 ("net/mlx5: fs, add HWS packet reformat API function")
> Signed-off-by: Alexandre Cassen <acassen@corp.free.fr>
> ---
>   drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.c b/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.c
> index 5a172c572a68..44b311b4532d 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.c
> @@ -1398,8 +1398,8 @@ static void mlx5_cmd_hws_packet_reformat_dealloc(struct mlx5_flow_root_namespace
>   						    pr_data->data_size);
>   		break;
>   	case MLX5_REFORMAT_TYPE_L2_TO_L3_TUNNEL:
> -		pr_pool = mlx5_fs_get_pr_encap_pool(dev, &hws_pool->el2tol2tnl_pools,
> -						    MLX5HWS_ACTION_TYP_REFORMAT_L2_TO_TNL_L2,
> +		pr_pool = mlx5_fs_get_pr_encap_pool(dev, &hws_pool->el2tol3tnl_pools,
> +						    MLX5HWS_ACTION_TYP_REFORMAT_L2_TO_TNL_L3,
>   						    pr_data->data_size);
>   		break;
>   	case MLX5_REFORMAT_TYPE_L3_TUNNEL_TO_L2:

Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com>

Re: [PATCH net 1/2] net/mlx5: HWS, release L2 to L3 tunnel reformats to their own pool

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] net/mlx5: memory leak of pr_data->data in packet reformat dealloc
- [Medium] net/mlx5: TOCTOU race in packet reformat pool allocation
--

commit b8aadd3f3a4943df684cd9bcfb91cb735038141f
Author: Alexandre Cassen <acassen@corp.free.fr>

net/mlx5: HWS, release L2 to L3 tunnel reformats to their own pool

L2 to L3 tunnel reformats are now released to the el2tol3tnl pools.

> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.c b/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.c
> index 5a172c572a68f..44b311b4532d1 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.c
> @@ -1398,8 +1398,8 @@ static void mlx5_cmd_hws_packet_reformat_dealloc(struct mlx5_flow_root_namespace
>  						    pr_data->data_size);
>  		break;
>  	case MLX5_REFORMAT_TYPE_L2_TO_L3_TUNNEL:
> -		pr_pool = mlx5_fs_get_pr_encap_pool(dev, &hws_pool->el2tol2tnl_pools,
> -						    MLX5HWS_ACTION_TYP_REFORMAT_L2_TO_TNL_L2,
> +		pr_pool = mlx5_fs_get_pr_encap_pool(dev, &hws_pool->el2tol3tnl_pools,
> +						    MLX5HWS_ACTION_TYP_REFORMAT_L2_TO_TNL_L3,
>  						    pr_data->data_size);

[Severity: Medium]
Could this call to mlx5_fs_get_pr_encap_pool() result in a time-of-check to
time-of-use race?

If multiple threads concurrently attempt to offload TC rules requiring a new
packet reformat pool of the same size, they might race locklessly. Both
threads could evaluate xa_load() to NULL and race on xa_insert():

drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.c:mlx5_fs_get_pr_encap_pool() {
    ...
	pr_pool = xa_load(pr_pools, index);
	if (pr_pool)
		return pr_pool;
    ...
	err = xa_insert(pr_pools, index, pr_pool, GFP_KERNEL);
	if (err)
		goto cleanup_pr_pool;
    ...
}

Would the losing thread unconditionally propagate an -EBUSY error up instead
of retrying or recovering?

[Severity: Medium]
If mlx5_fs_get_pr_encap_pool() returns an error, does this code leak
pr_data->data?

Later in mlx5_cmd_hws_packet_reformat_dealloc(), the error path returns
immediately without freeing the data:

	if (!pkt_reformat->fs_hws_action.pr_data || IS_ERR(pr_pool)) {
		mlx5_core_err(ns->dev, "Failed release packet-reformat\n");
		return;
	}

Is a kfree(pr_data->data) missing in this error path prior to the return?

>  		break;
>  	case MLX5_REFORMAT_TYPE_L3_TUNNEL_TO_L2:

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261007143830.1733583-1-acassen@corp.free.fr?part=1

[PATCH net 2/2] net/mlx5: HWS, fix flow meter offset within its bulk

[Alexandre Cassen]

The flow meter action is bound to the first ASO object of the bulk but
the rule offset only indexes the meter within its own object. A rule
past the first object runs on the wrong meter.

Fixes: 82d3639ef7dc ("net/mlx5: fs, add support for flow meters HWS action")
Signed-off-by: Alexandre Cassen <acassen@corp.free.fr>
---
 drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.c b/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.c
index 44b311b4532d..54761754e657 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.c
@@ -928,6 +928,7 @@ static int mlx5_fs_fte_get_hws_actions(struct mlx5_flow_root_namespace *ns,
 			goto free_actions;
 		}
 		(*ractions)[num_actions].aso_meter.offset =
+			(fte_action->exe_aso.object_id - fte_action->exe_aso.base_id) * 2 +
 			fte_action->exe_aso.flow_meter.meter_idx;
 		(*ractions)[num_actions].aso_meter.init_color =
 			fte_action->exe_aso.flow_meter.init_color;
-- 
2.43.0

Re: [PATCH net 2/2] net/mlx5: HWS, fix flow meter offset within its bulk

[sashiko-bot]

> The flow meter action is bound to the first ASO object of the bulk but
> the rule offset only indexes the meter within its own object. A rule
> past the first object runs on the wrong meter.
> 
> Fixes: 82d3639ef7dc ("net/mlx5: fs, add support for flow meters HWS action")
> Signed-off-by: Alexandre Cassen <acassen@corp.free.fr>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261007143830.1733583-1-acassen@corp.free.fr?part=2

Re: [PATCH net 2/2] net/mlx5: HWS, fix flow meter offset within its bulk

[Moshe Shemesh]

On 10/7/2026 5:38 PM, Alexandre Cassen wrote:
> 
> The flow meter action is bound to the first ASO object of the bulk but
> the rule offset only indexes the meter within its own object. A rule
> past the first object runs on the wrong meter.
> 
> Fixes: 82d3639ef7dc ("net/mlx5: fs, add support for flow meters HWS action")
> Signed-off-by: Alexandre Cassen <acassen@corp.free.fr>

Reviewed-by: Moshe Shemesh <moshe@nvidia.com>

Thanks.
> ---
>   drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.c | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.c b/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.c
> index 44b311b4532d..54761754e657 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.c
> @@ -928,6 +928,7 @@ static int mlx5_fs_fte_get_hws_actions(struct mlx5_flow_root_namespace *ns,
>                          goto free_actions;
>                  }
>                  (*ractions)[num_actions].aso_meter.offset =
> +                       (fte_action->exe_aso.object_id - fte_action->exe_aso.base_id) * 2 +
>                          fte_action->exe_aso.flow_meter.meter_idx;
>                  (*ractions)[num_actions].aso_meter.init_color =
>                          fte_action->exe_aso.flow_meter.init_color;
> --
> 2.43.0
> 

Re: [PATCH net 0/2] net/mlx5: HWS, fix reformat release and meter offset

[netdev-bot+sinfo]

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - What hardware the change was tested on. For driver fixes please
   mention the device (and if relevant firmware version) used for
   testing, or say that the change was not tested on real hardware.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.

The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.