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
