Re: [PATCH 2/2] RDMA/nldev: Guard against NULL ucontext in resource dumps

[Jason Gunthorpe <jgg@ziepe.ca>]

On Wed, Aug 12, 2026 at 08:32:49PM +0800, Yili Zhang wrote:
> Hi Jason,
> 
> Thanks for the review.  After re-reading your feedback and re-examining
> the crash log, I think I mis-characterized the root cause in my original
> patches.  Let me lay out what the log actually shows, because I'd like
> to get the fix on the right track.
> 
> The crash is a three-stage sequence, all from the same host
> (6.1.52 + MLNX_OFED 24.10):

You have to provide an analyis from top of tree upstream kernel if you
want help from this mailing list.

>   Stage 1 - a create_qp failure:
>     [24805924.400] mlx5_3: create_qp:3323:(pid 2758615): Create QP type 2 failed
> 
>   Stage 2 - on process exit, ib_uverbs_close() could not tear down the
>   process's CQs and fell into the DRIVER_FAILURE fallback:
>     [24805924.747] WARNING: ... rdma_core.c:945 uverbs_destroy_ufile_hw
>       Call Trace:
>         uverbs_destroy_ufile_hw
>         ib_uverbs_close
>         __fput

That's not supposed to happen.

> To be concrete about why it persists: under the current code, once the
> DRIVER_FAILURE fallback runs, the leaked object's restrack entry is
> never actively removed.  The CQ case:

And I think this was just fixed recently.

Jason