netdev - [PATCH] net/mlx5e: Again mutually exclude RX-FCS and RX-port-timestamp

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: Windows password security audit tool. GUI, reports in PDF.

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

Date: Thu,  5 Oct 2023 22:37:06 -0700
From: Will Mortensen <will@...rahop.com>
To: netdev@...r.kernel.org
Cc: Will Mortensen <will@...rahop.com>,
	Charlotte Tan <charlotte@...rahop.com>,
	Adham Faris <afaris@...dia.com>,
	Aya Levin <ayal@...dia.com>,
	Tariq Toukan <tariqt@...dia.com>,
	Moshe Shemesh <moshe@...dia.com>,
	Saeed Mahameed <saeedm@...dia.com>
Subject: [PATCH] net/mlx5e: Again mutually exclude RX-FCS and RX-port-timestamp

Commit 1e66220948df8 ("net/mlx5e: Update rx ring hw mtu upon each rx-fcs
flag change") seems to have accidentally inverted the logic added in
commit 0bc73ad46a76 ("net/mlx5e: Mutually exclude RX-FCS and
RX-port-timestamp").

The impact of this is a little unclear since it seems the FCS scattered
with RX-FCS is (usually?) correct regardless.

Fixes: 1e66220948df8 ("net/mlx5e: Update rx ring hw mtu upon each rx-fcs flag change")
Tested-by: Charlotte Tan <charlotte@...rahop.com>
Reviewed-by: Charlotte Tan <charlotte@...rahop.com>
Cc: Adham Faris <afaris@...dia.com>
Cc: Aya Levin <ayal@...dia.com>
Cc: Tariq Toukan <tariqt@...dia.com>
Cc: Moshe Shemesh <moshe@...dia.com>
Cc: Saeed Mahameed <saeedm@...dia.com>
Signed-off-by: Will Mortensen <will@...rahop.com>
---
For what it's worth, regardless of this change the PCMR register behaves
unexpectedly in our testing on NICs where rx_ts_over_crc_cap is 1 (i.e.
where rx_ts_over_crc is supported), such as ConnectX-7 running firmware
28.37.1014. For example, fcs_chk is always 0, and rx_ts_over_crc can
never be set to 1 after being set to 0. On ConnectX-5, where
rx_ts_over_crc_cap is 0, fcs_chk behaves as expected.

We'll probably be opening a support case about that after we test more,
but I mention it here because it makes FCS-related testing confusing.

 drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index a2ae791538ed..acb40770cf0c 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -3952,13 +3952,14 @@ static int set_feature_rx_fcs(struct net_device *netdev, bool enable)
 	struct mlx5e_channels *chs = &priv->channels;
 	struct mlx5e_params new_params;
 	int err;
+	bool rx_ts_over_crc = !enable;
 
 	mutex_lock(&priv->state_lock);
 
 	new_params = chs->params;
 	new_params.scatter_fcs_en = enable;
 	err = mlx5e_safe_switch_params(priv, &new_params, mlx5e_set_rx_port_ts_wrap,
-				       &new_params.scatter_fcs_en, true);
+				       &rx_ts_over_crc, true);
 	mutex_unlock(&priv->state_lock);
 	return err;
 }
-- 
2.34.1