[PATCH net V2 0/4] net/mlx5: SD LAG and devcom stability fixes
From: Tariq Toukan <tariqt@nvidia.com>
Date: 2026-09-06 07:14:41
Also in:
linux-rdma, lkml
Hi, This series by Shay fixes four bugs in the Socket Direct LAG and devcom subsystems, all related to initialization/teardown ordering and concurrent access to the LAG device. Regards, Tariq Internal sashiko comment:
quoted hunk
@@ -342,7 +342,14 @@ static void sd_lag_init(struct mlx5_core_dev *dev) return; } +recheck: mutex_lock(&ldev->lock); + if (ldev->mode_changes_in_progress) { + mutex_unlock(&ldev->lock); + msleep(100); + goto recheck; +
}
+
Does this open-coded retry loop reimplement a wait mechanism without immediate wakeups or fairness? It looks like we are polling the mode_changes_in_progress flag using a hard coded msleep(100). Could this unnecessarily delay the initialization path if the condition clears much sooner than 100ms? Would it be better to use a proper synchronization primitive like a waitqueue here instead of an ad-hoc flag loop? [SD] This is the same check as in mlx5_lag_remove_mdev(). I agree we need to change it, but this is net-next material V2: - Fix git am apply error, and move pre-replies to cover letter. V1: https://lore.kernel.org/all/20260902163716.3656279-1-tariqt@nvidia.com/ (local) Shay Drory (4): net/mlx5: SD, serialize SD LAG init/cleanup against LAG mode changes net/mlx5: devcom, Base component size on linked devices net/mlx5: SD, unload reps on shared FDB create error path net/mlx5: LAG, reload IB reps of LAG master before the rest .../net/ethernet/mellanox/mlx5/core/eswitch.c | 2 +- .../net/ethernet/mellanox/mlx5/core/lag/lag.c | 74 ++++++++++++------- .../mellanox/mlx5/core/lag/shared_fdb.c | 1 + .../ethernet/mellanox/mlx5/core/lib/devcom.c | 5 +- .../net/ethernet/mellanox/mlx5/core/lib/sd.c | 13 ++++ 5 files changed, 65 insertions(+), 30 deletions(-) base-commit: 2b4707a149a55e8fa75c9ef32b359d60f470a566 -- 2.44.0