Re: [PATCH] RDMA/mlx5: Use mlx5_cmd_is_down to detect PCIe Surprise Link Down

[Maher Sanalla <msanalla@nvidia.com>]

Hey Jian,

Yes. This is the fix we went with ultimately:
[1/1] RDMA/mlx5: Fix UMR hang in LAG error state unload
       https://git.kernel.org/rdma/rdma/c/ebc2164a4cd431

On 22/01/2026 11:36, Jian Wen wrote:
> *External email: Use caution opening links or attachments*
> 
> 
> Hi Maher,
> 
> Has the fix released yet?
> 
> Thanks.
> 
> 
> Maher Sanalla <msanalla@nvidia.com <mailto:msanalla@nvidia.com>>于2025年 
> 10月16日 周四21:32写道：
> 
> 
> 
>     On 09/10/2025 21:02, Jason Gunthorpe wrote:
>      > External email: Use caution opening links or attachments
>      >
>      >
>      > On Thu, Oct 09, 2025 at 10:23:20PM +0800, Jian Wen wrote:
>      >> --- a/drivers/infiniband/hw/mlx5/umr.c
>      >> +++ b/drivers/infiniband/hw/mlx5/umr.c
>      >> @@ -254,7 +254,7 @@ static int mlx5r_umr_post_send(struct ib_qp
>     *ibqp, u32 mkey, struct ib_cqe *cqe,
>      >>        unsigned int idx;
>      >>        int size, err;
>      >>
>      >> -     if (unlikely(mdev->state == MLX5_DEVICE_STATE_INTERNAL_ERROR))
>      >> +     if (unlikely(mlx5_cmd_is_down(mdev)))
>      >>                return -EIO;
>      >
>      > I feel like this is just changing the race around..
>      >
>      > The removal flow for the device is different if the HW is working
>     than
>      > if it isn't.
>      >
>      > If it isn't working then the removal should disable and cancel
>     all the
>      > UMRs, using the umrc->lock. Otherwise there will be dead threads
>      > floating around. It should also be setting
>      > MLX5_DEVICE_STATE_INTERNAL_ERROR way at the start of removal.
>      >
>      > So IDK, maybe check mlx5_cmd_is_down() and trigger the flow to
>      > activate INTERNAL_ERROR befor doing anything else?
>      >
>      > Jason
>      >
> 
>     I agree with Jason concern. While this may serve as a workaround for
>     certain cases, the race condition still exists. We’re aware of this
>     issue and are working on a proper fix. The intended solution is that
>     when the device enters an error state, the UMR state should transition
>     directly to error as well, preventing any new UMRs from being posted.
> 
>     Maher
>