Linux RDMA and InfiniBand development
 help / color / mirror / Atom feed
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

  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