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

From: Jason Gunthorpe

Date: Wed Aug 12 2026 - 20:05:05 EST


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