Re: [PATCH rdma-next v6 7/9] RDMA/bnxt_re: Enhance dpi lifecycle logic in doorbell uapis

[Jason Gunthorpe <jgg@ziepe.ca>]

On Tue, May 19, 2026 at 02:57:16PM +0530, Sriharsha Basavapatna wrote:
> On Mon, May 18, 2026 at 9:17 PM Sriharsha Basavapatna
> <sriharsha.basavapatna@broadcom.com> wrote:
> >
> > If the DPI is freed when the dbr object is freed, but if the
> > process has not unmapped the page yet, then the DPI slot could
> > get reallocated to another process while the original process
> > still has it mapped. To prevent this, save the DPI info in the
> > mmap entry during dbr allocation and free the DPI slot from
> > bnxt_re_mmap_free(), which enures that there are no references
> > to it.
> >
> > This change is needed to support doorbell allocation to QPs
> > in the next patch.
> >
> > Signed-off-by: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
> > Reviewed-by: Selvin Xavier <selvin.xavier@broadcom.com>
> > ---
> >  drivers/infiniband/hw/bnxt_re/ib_verbs.c |  4 ++++
> >  drivers/infiniband/hw/bnxt_re/ib_verbs.h |  1 +
> >  drivers/infiniband/hw/bnxt_re/uapi.c     | 12 ++++++++++--
> >  3 files changed, 15 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/infiniband/hw/bnxt_re/ib_verbs.c b/drivers/infiniband/hw/bnxt_re/ib_verbs.c
> > index 9fd85d81bcea..b8e46feafee7 100644
> > --- a/drivers/infiniband/hw/bnxt_re/ib_verbs.c
> > +++ b/drivers/infiniband/hw/bnxt_re/ib_verbs.c
> > @@ -4943,6 +4943,10 @@ void bnxt_re_mmap_free(struct rdma_user_mmap_entry *rdma_entry)
> >         bnxt_entry = container_of(rdma_entry, struct bnxt_re_user_mmap_entry,
> >                                   rdma_entry);
> >
> > +       if (bnxt_entry->mmap_flag == BNXT_RE_MMAP_UC_DB && bnxt_entry->uctx)
> > +               bnxt_qplib_free_uc_dpi(&bnxt_entry->uctx->rdev->qplib_res,
> > +                                      &bnxt_entry->dpi);
> > +
> >         kfree(bnxt_entry);
> >  }
> There's a sashiko warning on this change:
> 
> "Also, does this introduce a use-after-free during device hot-unplug?
> During hot-unplug, the RDMA core tears down the ib_ucontext (which
> embeds bnxt_re_ucontext) synchronously. However, active VMAs outlive
> the ucontext because hot-unplug only zaps the PTEs without closing the
> VMAs. When the process later exits or manually unmaps the memory,
> bnxt_re_mmap_free() is triggered. Will dereferencing
> bnxt_entry->uctx->rdev->qplib_res result in a use-after-free since the
> uctx has already been freed?"

Hmm! That is a pretty reasonable assumption..

> ufile_destroy_ucontext(reason == RDMA_REMOVE_DRIVER_REMOVE) -->
> uverbs_user_mmap_disassociate() --> rdma_user_mmap_entry_put() -->
> rdma_user_mmap_entry_free() --> ucontext->device->ops.mmap_free()

Yes, that's right. The disassociate removes the references from all
the VMAs so it should always eventually call free.

However, it would be best if we didn't have this code in the free
callback at all, ideally the destruction of the object will happen in
the uobject destructor not the mmap free. However, I think we lack the
ability to do that right now.

Jason