Re: [PATCH mlx5-next 10/10] mlx5: Move data direct implementation to mlx5_core

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] mlx5: fatal device probe failure on optional data direct init error
--

commit 99d3c5a833c6ca3bd3a1b016b15bbb8a8b597a79
Author: Dragos Tatulea <dtatulea@nvidia.com>

mlx5: Move data direct implementation to mlx5_core

This commit moves the data direct implementation from mlx5_ib to mlx5_core
so it can be used by netdev devices. The data direct initialization is moved
to mlx5_load() and resource creation is managed by the core driver.

> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/data_direct.c b/drivers/net/ethernet/mellanox/mlx5/core/data_direct.c
> rename from drivers/infiniband/hw/mlx5/data_direct.c
> rename to drivers/net/ethernet/mellanox/mlx5/core/data_direct.c
> index 3878c4aebb2c6..67717110feab0 100644
> --- a/drivers/infiniband/hw/mlx5/data_direct.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/data_direct.c

[ ... ]

> -	err = mlx5_data_direct_query_vuid(ibdev->mdev, reg->vuid);
> +	err = mlx5_data_direct_query_vuid(mdev, reg->vuid);
>  	if (err) {
> -		mlx5_ib_warn(ibdev, "Failed to query VUID, disabling data direct, err=%d\n",
> -			     err);
> +		mlx5_core_warn(mdev,
> +			       "Failed to query VUID, disabling data direct, err=%d\n",
> +			       err);
>  		kfree(reg);
> -		return err;
> +		return -EINVAL;
>  	}

[Severity: High]
In mlx5_data_direct_init(), does this code inadvertently cause a fatal probe
failure? The warning claims the optional feature is being disabled, but
returning -EINVAL bubbles up and aborts the entire core driver probe. If the
intent is to gracefully disable the feature when the VUID query fails,
shouldn't it return 0 instead?

[ ... ]

> -int mlx5_data_direct_register(struct mlx5_ib_dev *ibdev,
> +int mlx5_data_direct_register(struct mlx5_core_dev *mdev,
>  			      struct notifier_block *nb)
>  {
>  	struct mlx5_data_direct_registration *reg;
>  
> -	if (!mlx5_data_direct_supported(ibdev->mdev))
> +	if (!mlx5_data_direct_supported(mdev))
>  		return 0;
>  
> -	reg = container_of(ibdev->data_direct,
> -			    struct mlx5_data_direct_registration, dd);
> +	reg = container_of(mdev->data_direct,
> +			   struct mlx5_data_direct_registration, dd);

[Severity: High]
If mlx5_data_direct_init() is modified to return 0 on failure to allow
graceful degradation, will this code in mlx5_data_direct_register() trigger
a NULL pointer dereference?

It appears mlx5_data_direct_supported() only checks hardware capabilities,
blindly assuming mdev->data_direct is allocated. Should
mlx5_data_direct_supported() also check if mdev->data_direct is valid, or
should there be an explicit check here?

[ ... ]

> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c b/drivers/net/ethernet/mellanox/mlx5/core/main.c
> index 643b4aac20336..34f0375b68513 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c

[ ... ]

> @@ -1339,8 +1340,14 @@ static int mlx5_load(struct mlx5_core_dev *dev)
>  	if (err)
>  		goto err_traps_reg;
>  
> +	err = mlx5_data_direct_init(dev);
> +	if (err)
> +		goto err_data_direct;
> +
>  	return 0;

[Severity: High]
Does propagating the error from mlx5_data_direct_init() here in mlx5_load()
unintentionally disable the entire NIC (both Ethernet and IB) when the
optional data direct initialization fails?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260917111422.4054862-1-tariqt@nvidia.com?part=10