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 07:29:08PM +0530, Sriharsha Basavapatna wrote:
> "Does tying the hardware DPI slot lifecycle to the VMA lifecycle allow
> userspace to exhaust the hardware DPI pool? If a process allocates a
> DBR object, maps it via mmap(), and then immediately destroys the DBR
> object, the uverbs object is freed (replenishing the process's general
> RDMA object quota). Since the active VMA keeps the mmap entry alive,
> bnxt_re_mmap_free() is not called, and the hardware DPI slot is
> leaked. Could a user repeat this process to hoard hardware DPI slots
> until the device's entire DPI table capacity is exhausted?"

Yes that's true, but nothing you can do about this without moving the
lifecycle to the uobject, which we don't have infrastructure for.

> Even without this change, the DBR_ALLOC() uverb allows a process to
> allocate multiple DPIs (that are meant to be distributed across QPs).
> We don't want to restrict it. Again here, the library properly handles
> this by unmapping and destroying each DBR object.

Yes, but there is a cgroup limit on the number of uobjs a driver can
create, so it can be technically limited.

Jason