netdev - Re: [PATCH 1/1] net/mlx5: query_mcia_reg fail logging at debug severity

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <40a43641-adfa-4fbe-902b-a6c436f3ccd6@nvidia.com>
Date: Tue, 28 Oct 2025 22:28:14 +0200
From: Gal Pressman <gal@...dia.com>
To: Matthew W Carlis <mattc@...estorage.com>, netdev@...r.kernel.org
Cc: saeedm@...dia.com, tariqt@...dia.com, mbloch@...dia.com,
 ashishk@...estorage.com, msaggi@...estorage.com, adailey@...estorage.com
Subject: Re: [PATCH 1/1] net/mlx5: query_mcia_reg fail logging at debug
 severity

On 28/10/2025 21:40, Matthew W Carlis wrote:
> Whenever a user or automation runs ethtool -m <eth> or an equivalent
> to mlx5 device & there is not any SFP module in that device the
> kernel log is spammed with ""query_mcia_reg failed: status:" which
> is really not that informative to the user who already knows that
> their command failed. 

Assuming the user knows why the command failed is a big assumption, most
users don't. These status errors are indicative of more than one type of
error.
And if he knows, I would expect him to not run the command again?

BTW, we have a bug that returns success in case of an error in module
EEPROM query so the user doesn't even know that the command failed other
than seeing the error message.
We'll push a fix for that in the next few days.

Since the severity is logged at error severity
> the log message cannot be disabled via dyndbg etc...
> 
> Signed-off-by: Matthew W Carlis <mattc@...estorage.com>
> 
>  100.0% drivers/net/ethernet/mellanox/mlx5/core/
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/port.c b/drivers/net/ethernet/mellanox/mlx5/core/port.c
> index aa9f2b0a77d3..e1c93a96e479 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/port.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/port.c
> @@ -310,7 +310,7 @@ static int mlx5_query_module_id(struct mlx5_core_dev *dev, int module_num,
>  
>  	status = MLX5_GET(mcia_reg, out, status);
>  	if (status) {
> -		mlx5_core_err(dev, "query_mcia_reg failed: status: 0x%x\n",
> +		mlx5_core_dbg(dev, "query_mcia_reg failed: status: 0x%x\n",
>  			      status);
>  		return -EIO;
>  	}
> @@ -394,7 +394,7 @@ static int mlx5_query_mcia(struct mlx5_core_dev *dev,
>  
>  	status = MLX5_GET(mcia_reg, out, status);
>  	if (status) {
> -		mlx5_core_err(dev, "query_mcia_reg failed: status: 0x%x\n",
> +		mlx5_core_dbg(dev, "query_mcia_reg failed: status: 0x%x\n",
>  			      status);
>  		return -EIO;
>  	}

Both of these functions are called from mlx5e_get_module_eeprom() which
has its own error print regardless, so this doesn't really prevent the
"spam".