On Thu, Sep 03, 2020 at 08:35:17AM +0300, Leon Romanovsky wrote: > On Wed, Sep 02, 2020 at 09:20:48PM -0300, Jason Gunthorpe wrote: > > On Sun, Aug 30, 2020 at 11:40:06AM +0300, Leon Romanovsky wrote: > > > /** > > > - * ib_free_cq_user - free a completion queue > > > + * ib_free_cq - free a completion queue > > > * @cq: completion queue to free. > > > - * @udata: User data or NULL for kernel object > > > */ > > > -void ib_free_cq_user(struct ib_cq *cq, struct ib_udata *udata) > > > +void ib_free_cq(struct ib_cq *cq) > > > { > > > - if (WARN_ON_ONCE(atomic_read(&cq->usecnt))) > > > - return; > > > - if (WARN_ON_ONCE(cq->cqe_used)) > > > - return; > > > + WARN_ON_ONCE(atomic_read(&cq->usecnt)); > > > > In this case we expect ops.destroy_cq to fail, so no sense in > > continuing, leak everything, the ULP is buggy. > > I disagree, we should clean as much as possible and leave the HW object. There is no reason, this just creates possible data corruption. Once these WARN_ONs are hit, the system is leaking memory. It doesn't really matter how much is leaked, and there is no reason to try to minimize the leaking. Jason