public inbox for linux-rdma@vger.kernel.org
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Devesh Sharma <devesh.sharma@broadcom.com>
Cc: Jason Gunthorpe <jgg@mellanox.com>,
	"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
	"dledford@redhat.com" <dledford@redhat.com>
Subject: Re: [PATCH for-next 1/7] RDMA/bnxt_re: Refactor queue pair creation code
Date: Mon, 27 Jan 2020 11:27:57 +0200	[thread overview]
Message-ID: <20200127092757.GN3870@unreal> (raw)
In-Reply-To: <CANjDDBigH2EvkKVoFrRc0hdMG+1czSg0DChTmkj9M3Kzt2d=gQ@mail.gmail.com>

On Mon, Jan 27, 2020 at 01:46:13PM +0530, Devesh Sharma wrote:
> On Mon, Jan 27, 2020 at 1:43 PM Devesh Sharma
> <devesh.sharma@broadcom.com> wrote:
> >
> > On Sat, Jan 25, 2020 at 11:16 PM Jason Gunthorpe <jgg@mellanox.com> wrote:
> > >
> > > On Fri, Jan 24, 2020 at 12:52:39AM -0500, Devesh Sharma wrote:
> > > > +static int bnxt_re_destroy_gsi_sqp(struct bnxt_re_qp *qp)
> > > > +{
> > > > +     struct bnxt_re_qp *gsi_sqp;
> > > > +     struct bnxt_re_ah *gsi_sah;
> > > > +     struct bnxt_re_dev *rdev;
> > > > +     int rc = 0;
> > > > +
> > > > +     rdev = qp->rdev;
> > > > +     gsi_sqp = rdev->gsi_ctx.gsi_sqp;
> > > > +     gsi_sah = rdev->gsi_ctx.gsi_sah;
> > > > +
> > > > +     /* remove from active qp list */
> > > > +     mutex_lock(&rdev->qp_lock);
> > > > +     list_del(&gsi_sqp->list);
> > > > +     atomic_dec(&rdev->qp_count);
> > > > +     mutex_unlock(&rdev->qp_lock);
> > > > +
> > > > +     dev_dbg(rdev_to_dev(rdev), "Destroy the shadow AH\n");
> > > > +     bnxt_qplib_destroy_ah(&rdev->qplib_res,
> > > > +                           &gsi_sah->qplib_ah,
> > > > +                           true);
> > > > +     bnxt_qplib_clean_qp(&qp->qplib_qp);
> > > > +
> > > > +     dev_dbg(rdev_to_dev(rdev), "Destroy the shadow QP\n");
> > > > +     rc = bnxt_qplib_destroy_qp(&rdev->qplib_res, &gsi_sqp->qplib_qp);
> > > > +     if (rc) {
> > > > +             dev_err(rdev_to_dev(rdev), "Destroy Shadow QP failed");
> > > > +             goto fail;
> > > > +     }
> > > > +     bnxt_qplib_free_qp_res(&rdev->qplib_res, &gsi_sqp->qplib_qp);
> > > > +
> > > > +     kfree(rdev->gsi_ctx.sqp_tbl);
> > > > +     kfree(gsi_sah);
> > > > +     kfree(gsi_sqp);
> > > > +     rdev->gsi_ctx.gsi_sqp = NULL;
> > > > +     rdev->gsi_ctx.gsi_sah = NULL;
> > > > +     rdev->gsi_ctx.sqp_tbl = NULL;
> > > > +
> > > > +     return 0;
> > > > +fail:
> > > > +     mutex_lock(&rdev->qp_lock);
> > > > +     list_add_tail(&gsi_sqp->list, &rdev->qp_list);
> > > > +     atomic_inc(&rdev->qp_count);
> > > > +     mutex_unlock(&rdev->qp_lock);
> > > > +     return rc;
> > >
> > > This error unwind approach looks racy. destroy is not allowed to
> > > fail, so why all this mess?
> > True, the unwind is not required, even if the driver wants to keep it
> > for debugging purpose, the zombie resource would give rise to
> > confusion.
> > >
> > > >  /* Queue Pairs */
> > > >  int bnxt_re_destroy_qp(struct ib_qp *ib_qp, struct ib_udata *udata)
> > > >  {
> > > > @@ -750,10 +797,18 @@ int bnxt_re_destroy_qp(struct ib_qp *ib_qp, struct ib_udata *udata)
> > > >       unsigned int flags;
> > > >       int rc;
> > > >
> > > > +     mutex_lock(&rdev->qp_lock);
> > > > +     list_del(&qp->list);
> > > > +     atomic_dec(&rdev->qp_count);
> > > > +     mutex_unlock(&rdev->qp_lock);
> > > >       bnxt_qplib_flush_cqn_wq(&qp->qplib_qp);
> > > >       rc = bnxt_qplib_destroy_qp(&rdev->qplib_res, &qp->qplib_qp);
> > > >       if (rc) {
> > > >               dev_err(rdev_to_dev(rdev), "Failed to destroy HW QP");
> > > > +             mutex_lock(&rdev->qp_lock);
> > > > +             list_add_tail(&qp->list, &rdev->qp_list);
> > > > +             atomic_inc(&rdev->qp_count);
> > > > +             mutex_unlock(&rdev->qp_lock);
> > > >               return rc;
> > > >       }
> > >
> > > More..
> > Let me see if I can remove it in this series, else future series would
> > remove it.
> > >
> > > Jason
>
> At the top level, if provider driver is so keen on returning success
> in any case, should we change the return type to void of
> ib_destroy_xx() hooks?

We are doing it but in extremely slow way. Patches are welcomed.

Thanks

  reply	other threads:[~2020-01-27  9:28 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-24  5:52 [PATCH for-next 0/7] Refactor control path of bnxt_re driver Devesh Sharma
2020-01-24  5:52 ` [PATCH for-next 1/7] RDMA/bnxt_re: Refactor queue pair creation code Devesh Sharma
2020-01-24 11:23   ` Leon Romanovsky
2020-01-25 17:03     ` Devesh Sharma
2020-01-25 18:50       ` Leon Romanovsky
2020-01-27  7:39         ` Devesh Sharma
2020-01-30  6:04           ` Devesh Sharma
2020-01-25 17:46   ` Jason Gunthorpe
2020-01-27  8:13     ` Devesh Sharma
2020-01-27  8:16       ` Devesh Sharma
2020-01-27  9:27         ` Leon Romanovsky [this message]
2020-01-27  9:26       ` Leon Romanovsky
2020-01-27 11:31         ` Devesh Sharma
2020-01-30  6:04       ` Devesh Sharma
2020-01-30 13:37   ` Parav Pandit
2020-01-30 16:03     ` Devesh Sharma
2020-01-24  5:52 ` [PATCH for-next 2/7] RDMA/bnxt_re: Replace chip context structure with pointer Devesh Sharma
2020-01-25 18:03   ` Jason Gunthorpe
2020-01-27  7:39     ` Devesh Sharma
2020-01-27  8:04       ` Leon Romanovsky
2020-01-27 11:17         ` Devesh Sharma
2020-01-28 20:15       ` Jason Gunthorpe
2020-01-30  6:05         ` Devesh Sharma
2020-01-24  5:52 ` [PATCH for-next 3/7] RDMA/bnxt_re: Refactor hardware queue memory allocation Devesh Sharma
2020-01-24  5:52 ` [PATCH for-next 4/7] RDMA/bnxt_re: Refactor net ring allocation function Devesh Sharma
2020-01-26 14:29   ` Leon Romanovsky
2020-01-27  7:40     ` Devesh Sharma
2020-01-27  8:02       ` Leon Romanovsky
2020-01-27 11:25         ` Devesh Sharma
2020-01-27 12:44           ` Leon Romanovsky
2020-01-27 14:14             ` Devesh Sharma
2020-01-28 18:09               ` Jason Gunthorpe
2020-01-28  0:35       ` Jason Gunthorpe
2020-01-28  2:43         ` Devesh Sharma
2020-01-28 18:09           ` Jason Gunthorpe
2020-01-29  8:29             ` Devesh Sharma
2020-01-24  5:52 ` [PATCH for-next 5/7] RDMA/bnxt_re: Refactor command queue management code Devesh Sharma
2020-01-24  5:52 ` [PATCH for-next 6/7] RDMA/bnxt_re: Refactor notification " Devesh Sharma
2020-01-24  5:52 ` [PATCH for-next 7/7] RDMA/bnxt_re: Refactor doorbell management functions Devesh Sharma
2020-01-25 18:04 ` [PATCH for-next 0/7] Refactor control path of bnxt_re driver Jason Gunthorpe
2020-01-27  7:39   ` Devesh Sharma

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200127092757.GN3870@unreal \
    --to=leon@kernel.org \
    --cc=devesh.sharma@broadcom.com \
    --cc=dledford@redhat.com \
    --cc=jgg@mellanox.com \
    --cc=linux-rdma@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox