Re: [PATCH 2/2] RDMA/nldev: Guard against NULL ucontext in resource dumps
Jason Gunthorpe <[email protected]>
| Newsgroups | org.kernel.vger.linux-rdma,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
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