Re: [PATCH v2 06/16] RDMA/hns: Fix xarray race in hns_roce_create_srq()

[Jason Gunthorpe <jgg@nvidia.com>]

On Tue, Apr 07, 2026 at 09:39:52PM +0800, Junxian Huang wrote:
> 
> 
> On 2026/4/7 1:40, Jason Gunthorpe wrote:
> > Sashiko points out that once the srq memory is stored into the xarray by
> > alloc_srqc() it can immediately be looked up by:
> > 
> > 	xa_lock(&srq_table->xa);
> > 	srq = xa_load(&srq_table->xa, srqn & (hr_dev->caps.num_srqs - 1));
> > 	if (srq)
> > 		refcount_inc(&srq->refcount);
> > 	xa_unlock(&srq_table->xa);
> > 
> > Which will fail refcount debug because the refcount is 0 and then crash:
> > 
> > 	srq->event(srq, event_type);
> > 
> > Because event is NULL.
> 
> I don't think this will actually happen because HW won't report an SRQ
> event before the SRQ is fully ready and actually used.

Probably, but also maybe there is some crazy race where EQ event can
be generated and the SRQ cycled before it is collected..

There is also a second bug here that Shashiko noticed on this patch
that the order is wrong, the goto unwind in create will call
free_srqc() but it hasn't yet setup the completion. I will fix that in
a v3..

> From the perspective of coding, I'm fine with this change, but since
> there is similar logic for QP event, could you also apply this change
> to QP?

Sure

Jason