Re: [PATCH rdma-next v2 03/11] RDMA/core: Preserve restrack resource ID on reinsertion

[Jason Gunthorpe <jgg@ziepe.ca>]

On Tue, Apr 07, 2026 at 12:18:07PM +0300, Patrisious Haddad wrote:
> 
> On 4/7/2026 1:23 AM, Jason Gunthorpe wrote:
> > External email: Use caution opening links or attachments
> > 
> > 
> > On Mon, Apr 06, 2026 at 12:11:14PM +0300, Edward Srouji wrote:
> > > From: Patrisious Haddad <phaddad@nvidia.com>
> > > 
> > > rdma_restrack_add() currently always allocates a new ID via
> > > xa_alloc_cyclic(), regardless of whether res->id is already set.
> > > This change makes sure that the object’s ID remains the same across
> > > removal and reinsertion to restrack.
> > It would be better to somehow pre-delete it so it is still in the
> > xarray but somehow blocked and then allow un pre-deleting. del/add
> > pairs are not a good design.
> Usually del/add pairs not good due to re-addition possibility of failure ,
> here that cant happen ... so any reason why it is still considered bad ?

xa_insert can fail, so it's still a bad idea.

I do not want to see random calls to restrack_add ignoring the return
code. Some kind of restrack_abort_delete() with a void return and no
possibility for failure is required.

> The problem with marking as deletion here is that it is not only the xarray
> that is being done at the delete operation (there is restrack_put and
> wait_for_completion inside the restrack del to sync with other threads that
> are ongoing).

I think the main point of pre-delete is to fence the concurrency.

So what you probably want is to leave the entry in the xarray, or
perhaps set it to XA_ZERO and drive the refcount to zero so that none
of the xa_load patterns can return it. This is enough to fence the
concurrency while allowing abort to not require any memory allocation.

I remember looking at this once and it was complex to unravel all the
things that rdma_restrack_del with valid and no_track so I gave up..

Jason