From: sashiko-bot@kernel.org
To: "Yishai Hadas" <yishaih@nvidia.com>
Cc: linux-rdma@vger.kernel.org
Subject: Re: [PATCH V1 rdma-next 01/24] net/mlx5: Add mlx5_trigger_health_work_force()
Date: Wed, 11 Nov 2026 13:46:44 +0000 [thread overview]
Message-ID: <sashiko-outbox-209086@kernel.org> (raw)
In-Reply-To: <20261110134320.34408-2-yishaih@nvidia.com>
Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] net/mlx5: stale force_fatal_report_work unloads device after
recovery
--
commit 0df37fc156d59f375d27165a97578e68ca1e9e3f
Author: Yishai Hadas <yishaih@nvidia.com>
net/mlx5: Add mlx5_trigger_health_work_force()
This commit adds mlx5_trigger_health_work_force() to queue a dedicated
health recovery work item that stops the firmware and forces the device
into MLX5_DEVICE_STATE_INTERNAL_ERROR even when the health sensors do not
report a fault.
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/health.c b/drivers/net/ethernet/mellanox/mlx5/core/health.c
> index aeeb136f5ebc7..e76351860b154 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/health.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/health.c
> @@ -627,18 +627,11 @@ mlx5_fw_fatal_reporter_dump(struct devlink_health_reporter *reporter,
> return err;
> }
>
> -static void mlx5_fw_fatal_reporter_err_work(struct work_struct *work)
> +static void mlx5_fw_fatal_reporter_err(struct mlx5_core_dev *dev, bool forced)
> {
> struct mlx5_fw_reporter_ctx fw_reporter_ctx;
> - struct mlx5_core_health *health;
> - struct mlx5_core_dev *dev;
> - struct devlink *devlink;
> - struct mlx5_priv *priv;
> -
> - health = container_of(work, struct mlx5_core_health, fatal_report_work);
> - priv = container_of(health, struct mlx5_priv, health);
> - dev = container_of(priv, struct mlx5_core_dev, priv);
> - devlink = priv_to_devlink(dev);
> + struct mlx5_core_health *health = &dev->priv.health;
> + struct devlink *devlink = priv_to_devlink(dev);
>
> mutex_lock(&dev->intf_state_mutex);
> if (test_bit(MLX5_DROP_HEALTH_WORK, &health->flags)) {
> @@ -646,8 +639,39 @@ static void mlx5_fw_fatal_reporter_err_work(struct work_struct *work)
> mutex_unlock(&dev->intf_state_mutex);
> return;
> }
> + if (forced) {
> + int err;
> +
> + /*
> + * Once the interface is down, the unload already removed the
> + * consumers that need the error flow. Once the cmd interface
> + * is down, the path that brought it down owns the flush and
> + * the recovery.
> + */
> + if (mlx5_cmd_is_down(dev) ||
> + !test_bit(MLX5_INTERFACE_STATE_UP, &dev->intf_state)) {
> + mutex_unlock(&dev->intf_state_mutex);
> + return;
> + }
> + /*
> + * The firmware might still be running, so stop it first. Do it
> + * under intf_state_mutex, so the cmd interface is valid.
> + */
> + mlx5_stop_health_poll(dev, false);
> + err = mlx5_cmd_fast_teardown_hca(dev);
> + if (err)
> + err = mlx5_cmd_force_teardown_hca(dev);
> + if (err)
> + mlx5_core_err(dev, "Failed to stop the device before forcing the error state, err %d\n",
> + err);
> + }
[Severity: Medium]
Can a force_fatal_report_work queued while recovery is already running on
health->wq tear down and unload the device right after it recovers?
Recovery runs synchronously on the single-threaded health->wq via
devlink_health_report() -> ... -> mlx5_recover_device() ->
mlx5_load_one_devl_locked(), which brings the command interface and
MLX5_INTERFACE_STATE_UP back up before the first work item finishes.
Consumers remain attached until mlx5_detach_device() runs during the
unload phase of recovery (for example while crdump collection or software
reset is in progress), and neither mlx5_unload_one_devl_locked() nor
mlx5_load_one_devl_locked() cancels a pending force_fatal_report_work:
health->wq consumer
mlx5_fw_fatal_reporter_err()
enter_error_state(dev, ...)
mlx5_trigger_health_work_force(dev)
queue_work(..., &force_fatal_report_work)
devlink_health_report(...)
...
mlx5_recover_device(dev)
mlx5_load_one_devl_locked(dev, true)
/* cmd and interface are back UP */
mlx5_fw_fatal_reporter_force_err_work()
mlx5_fw_fatal_reporter_err(dev, true)
/* mlx5_cmd_is_down() is false and
* MLX5_INTERFACE_STATE_UP is set */
mlx5_cmd_fast_teardown_hca(dev)
enter_error_state(dev, true)
devlink_health_report(...) -> -ECANCELED
mlx5_unload_one(dev, false) <-- unloads recovered device
Because fw_fatal_reporter is still within its graceful period from the
recovery that just completed, devlink_health_report() returns -ECANCELED
and mlx5_fw_fatal_reporter_err() unloads the freshly recovered driver.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261110134320.34408-1-yishaih@nvidia.com?part=1
next prev parent reply other threads:[~2026-11-11 13:46 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-10 13:42 [PATCH V1 rdma-next 00/24] mlx5: Adversarial mode for confidential computing guests Yishai Hadas
2026-11-10 13:42 ` [PATCH V1 rdma-next 01/24] net/mlx5: Add mlx5_trigger_health_work_force() Yishai Hadas
2026-11-11 13:46 ` sashiko-bot [this message]
2026-11-11 15:03 ` Yishai Hadas
2026-11-10 13:42 ` [PATCH V1 rdma-next 02/24] net/mlx5: Derive adversarial mode from CC guest memory encryption Yishai Hadas
2026-11-11 13:46 ` sashiko-bot
2026-11-10 13:42 ` [PATCH V1 rdma-next 03/24] net/mlx5: Add capability filtering in adversarial mode Yishai Hadas
2026-11-11 13:46 ` sashiko-bot
2026-11-11 15:51 ` Yishai Hadas
2026-11-10 13:43 ` [PATCH V1 rdma-next 04/24] net/mlx5: Catch too low max number of EQs Yishai Hadas
2026-11-11 13:46 ` sashiko-bot
2026-11-10 13:43 ` [PATCH V1 rdma-next 05/24] net/mlx5: Add macros for reading log-based caps Yishai Hadas
2026-11-11 13:46 ` sashiko-bot
2026-11-10 13:43 ` [PATCH V1 rdma-next 06/24] RDMA/mlx5: Reject QP transport types not enabled by FW capability Yishai Hadas
2026-11-11 13:46 ` sashiko-bot
2026-11-10 13:43 ` [PATCH V1 rdma-next 07/24] RDMA/mlx5: Require IB_QPT_DRIVER for the DC vendor QP types Yishai Hadas
2026-11-11 13:46 ` sashiko-bot
2026-11-10 13:43 ` [PATCH V1 rdma-next 08/24] RDMA/mlx5: Derive mlx5_ib_adversarial_mode global from mlx5_core adversarial API Yishai Hadas
2026-11-11 13:46 ` sashiko-bot
2026-11-10 13:43 ` [PATCH V1 rdma-next 09/24] RDMA/core: Suppress kverbs_provider for adversarial_mode devices Yishai Hadas
2026-11-11 13:46 ` sashiko-bot
2026-11-10 13:43 ` [PATCH V1 rdma-next 10/24] RDMA/mlx5: Remove duplicate mlx5_ib_umr_context struct Yishai Hadas
2026-11-11 13:46 ` sashiko-bot
2026-11-10 13:43 ` [PATCH V1 rdma-next 11/24] RDMA/mlx5: Introduce per-CQ poll_one hook in mlx5_ib_cq Yishai Hadas
2026-11-11 13:46 ` sashiko-bot
2026-11-10 13:43 ` [PATCH V1 rdma-next 12/24] RDMA/mlx5: Add shadow FIFO infrastructure for UMR completions Yishai Hadas
2026-11-11 13:46 ` sashiko-bot
2026-11-10 13:43 ` [PATCH V1 rdma-next 13/24] RDMA/mlx5: Verify UMR CQ polling against a hostile NIC Yishai Hadas
2026-11-11 13:46 ` sashiko-bot
2026-11-10 13:43 ` [PATCH V1 rdma-next 14/24] RDMA/mlx5: Keep the UMR QP failed once a forged CQE is detected Yishai Hadas
2026-11-11 13:46 ` sashiko-bot
2026-11-10 13:43 ` [PATCH V1 rdma-next 15/24] RDMA/mlx5: Block generic CQ poll path in adversarial mode Yishai Hadas
2026-11-11 13:46 ` sashiko-bot
2026-11-10 13:43 ` [PATCH V1 rdma-next 16/24] RDMA/core: Set the CQ comp_handler after its poll context is set up Yishai Hadas
2026-11-11 13:46 ` sashiko-bot
2026-11-10 13:43 ` [PATCH V1 rdma-next 17/24] RDMA/mlx5: Ignore completion events for a kernel CQ that is not ready Yishai Hadas
2026-11-11 13:46 ` sashiko-bot
2026-11-10 13:43 ` [PATCH V1 rdma-next 18/24] RDMA/mlx5: Validate EQE port and GSI port before indexing devr.ports[] Yishai Hadas
2026-11-11 13:46 ` sashiko-bot
2026-11-10 13:43 ` [PATCH V1 rdma-next 19/24] RDMA/mlx5: Validate firmware RQ/SQ state before sqrq_trans[] lookup Yishai Hadas
2026-11-11 13:46 ` sashiko-bot
2026-11-11 15:58 ` Yishai Hadas
2026-11-10 13:43 ` [PATCH V1 rdma-next 20/24] RDMA/mlx5: Clamp log_max_cq_sz shift in CQ size checks Yishai Hadas
2026-11-11 13:46 ` sashiko-bot
2026-11-10 13:43 ` [PATCH V1 rdma-next 21/24] RDMA/mlx5: Clamp log_max_* shifts in QP and WQ limit checks Yishai Hadas
2026-11-11 13:46 ` sashiko-bot
2026-11-10 13:43 ` [PATCH V1 rdma-next 22/24] RDMA/mlx5: Clamp log_max_* shifts in query_device and ucontext paths Yishai Hadas
2026-11-11 13:46 ` sashiko-bot
2026-11-10 13:43 ` [PATCH V1 rdma-next 23/24] RDMA/core: Report and enforce adversarial mode via GET_CONTEXT Yishai Hadas
2026-11-11 13:46 ` sashiko-bot
2026-11-10 13:43 ` [PATCH V1 rdma-next 24/24] RDMA/mlx5: Advertise adversarial mode via ib_device::adversarial_mode Yishai Hadas
2026-11-11 13:46 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sashiko-outbox-209086@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=yishaih@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox