linux-rdma.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Dakshaja Uppalapati <dakshaja@chelsio.com>,
	dledford@redhat.com, linux-rdma@vger.kernel.org,
	bharat@chelsio.com
Subject: Re: [PATCH for-rc] iw_cxgb4: Fix refcount underflow while destroying cqs.
Date: Thu, 22 Jul 2021 15:57:39 +0300	[thread overview]
Message-ID: <YPlrQ1Uu+OXxRJBF@unreal> (raw)
In-Reply-To: <20210722120607.GE1117491@nvidia.com>

On Thu, Jul 22, 2021 at 09:06:07AM -0300, Jason Gunthorpe wrote:
> On Thu, Jul 22, 2021 at 10:43:00AM +0300, Leon Romanovsky wrote:
> > On Wed, Jul 21, 2021 at 04:51:55PM +0530, Dakshaja Uppalapati wrote:
> > > Previous atomic increment decrement logic expects the atomic count
> > > to be '0' after the final decrement. Replacing atomic count with
> > > refcount does not allow that as refcount_dec() considers count of 1 as
> > > underflow. Therefore fix the current refcount logic by decrementing
> > > the refcount if one on the final deref in c4iw_destroy_cq().
> > > 
> > > Fixes: 7183451f846d (RDMA/cxgb4: Use refcount_t instead of atomic_t for reference counting")
> > > Signed-off-by: Dakshaja Uppalapati <dakshaja@chelsio.com>
> > > Reviewed-by: Potnuri Bharat Teja <bharat@chelsio.com>
> > >  drivers/infiniband/hw/cxgb4/cq.c | 3 +--
> > >  1 file changed, 1 insertion(+), 2 deletions(-)
> > 
> > 
> > Thanks, 
> > Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
> > 
> > We have plenty of such errors, worth to check them:
> > ➜  kernel git:(rdma-next) git grep refcount_read drivers/infiniband/ | grep -v WARN_ON
> > drivers/infiniband/core/device.c:	if (!refcount_read(&ib_dev->refcount))
> > drivers/infiniband/core/device.c:	if (refcount_read(&device->refcount) == 0 ||
> > drivers/infiniband/core/iwpm_util.c:	if (!refcount_read(&iwpm_admin.refcount)) {
> > drivers/infiniband/core/iwpm_util.c:	if (!refcount_read(&iwpm_admin.refcount)) {
> > drivers/infiniband/core/ucma.c:	if (refcount_read(&ctx->ref))
> > drivers/infiniband/hw/cxgb4/cq.c:	wait_event(chp->wait, !refcount_read(&chp->refcnt));
> > drivers/infiniband/hw/irdma/utils.c:			   refcount_read(&cqp_request->refcnt) == 1, 1000);
> > drivers/infiniband/hw/mlx5/mlx5_ib.h:	wait_event(mmkey->wait, refcount_read(&mmkey->usecount) == 0);
> > drivers/infiniband/hw/mlx5/mr.c:	    refcount_read(&mr->mmkey.usecount) != 0 &&
> 
> It isn't the read that is the problem, it is the naked dec.
> 
> This common pattern is just being done in an obtuse and arguably wrong
> way
> 
> It is supposed to look like this:
> 
> void ib_device_put(struct ib_device *device)
> {
>         if (refcount_dec_and_test(&device->refcount))
>                 complete(&device->unreg_completion);
> }
> 
> [..]
> 
>         ib_device_put(device);
>         wait_for_completion(&device->unreg_completion);
> 
> 
> Not use refcount_read() and a naked work queue
> 
> So I'd say these ones should be looked at:
> 
> drivers/infiniband/hw/cxgb4/cq.c:       refcount_dec(&chp->refcnt);
> drivers/infiniband/hw/hns/hns_roce_db.c:        refcount_dec(&db->u.user_page->refcount);
> drivers/infiniband/hw/irdma/cm.c:       refcount_dec(&cm_node->refcnt);
> drivers/infiniband/hw/irdma/cm.c:               refcount_dec(&listener->refcnt);
> drivers/infiniband/hw/irdma/cm.c:                       refcount_dec(&listener->refcnt);

Jason,

We are talking about two different issues that this refcount_read patch pointed.
You are focused on wrong usage of completion, I saw useless compare of
refcount_t with 0 that can't be.

I prepared series that cleans iwpm from this type of error:
 drivers/infiniband/core/iwpm_util.c:        if (!refcount_read(&iwpm_admin.refcount)) {
 drivers/infiniband/core/iwpm_util.c:        if (!refcount_read(&iwpm_admin.refcount)) {

Thanks

> 
> Jason

  reply	other threads:[~2021-07-22 12:57 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-21 11:21 [PATCH for-rc] iw_cxgb4: Fix refcount underflow while destroying cqs Dakshaja Uppalapati
2021-07-22  7:43 ` Leon Romanovsky
2021-07-22 12:06   ` Jason Gunthorpe
2021-07-22 12:57     ` Leon Romanovsky [this message]
2021-07-22 13:02       ` Jason Gunthorpe
2021-07-22 13:23         ` Dakshaja Uppalapati
2021-07-22 14:01         ` Leon Romanovsky
2021-07-22 14:02           ` Jason Gunthorpe
     [not found]             ` <20210803155919.GB11439@chelsio.com>
2021-08-03 16:09               ` Jason Gunthorpe

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=YPlrQ1Uu+OXxRJBF@unreal \
    --to=leon@kernel.org \
    --cc=bharat@chelsio.com \
    --cc=dakshaja@chelsio.com \
    --cc=dledford@redhat.com \
    --cc=jgg@nvidia.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;
as well as URLs for NNTP newsgroup(s).