public inbox for linux-rdma@vger.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@ziepe.ca>
To: Bernard Metzler <BMT@zurich.ibm.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>,
	Doug Ledford <dledford@redhat.com>,
	linux-rdma@vger.kernel.org
Subject: Re: [bug report] RDMA/siw: Fix SQ/RQ drain logic
Date: Fri, 25 Oct 2019 09:34:54 -0300	[thread overview]
Message-ID: <20191025123454.GH23952@ziepe.ca> (raw)
In-Reply-To: <OF9EE3BDCA.84D0CB33-ON0025849E.002C56C0-0025849E.002D6F03@notes.na.collabserv.com>

On Fri, Oct 25, 2019 at 08:16:15AM +0000, Bernard Metzler wrote:
> 
> >To: bmt@zurich.ibm.com
> >From: "Dan Carpenter" <dan.carpenter@oracle.com>
> >Date: 10/24/2019 10:39PM
> >Cc: linux-rdma@vger.kernel.org
> >Subject: [EXTERNAL] [bug report] RDMA/siw: Fix SQ/RQ drain logic
> >
> >Hello Bernard Metzler,
> >
> >The patch cf049bb31f71: "RDMA/siw: Fix SQ/RQ drain logic" from Oct 4,
> >2019, leads to the following static checker warning:
> >
> >	drivers/infiniband/sw/siw/siw_verbs.c:1079 siw_post_receive()
> >	error: locking inconsistency.  We assume 'read_sem:&qp->state_lock'
> >is both locked and unlocked at the start.
> >
> >drivers/infiniband/sw/siw/siw_verbs.c
> >   978  int siw_post_receive(struct ib_qp *base_qp, const struct
> >ib_recv_wr *wr,
> >   979                       const struct ib_recv_wr **bad_wr)
> >   980  {
> >   981          struct siw_qp *qp = to_siw_qp(base_qp);
> >   982          unsigned long flags;
> >   983          int rv = 0;
> >   984  
> >   985          if (qp->srq) {
> >   986                  *bad_wr = wr;
> >   987                  return -EOPNOTSUPP; /* what else from
> >errno.h? */
> >   988          }
> >   989          if (!qp->kernel_verbs) {
> >   990                  siw_dbg_qp(qp, "no kernel post_recv for user
> >mapped sq\n");
> >   991                  up_read(&qp->state_lock);
> >                        ^^^^^^^^^^^^^^^^^^^^^^^^
> >The patch changes the locking so this isn't held here and should be
> >released.  Should it be held, though?
> 
> Yes, this is a BUG. Thanks very much! There is no qp spinlock to 
> be held here. I moved that down to state checking. No need to
> hold the qp lock before. 
> 
> Shall I re-send, or can we just amend the patch,
> removing that single 'up_read()' line?

You need to send a new patch against for-next to fix this

Jason

      reply	other threads:[~2019-10-25 12:34 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-24 20:38 [bug report] RDMA/siw: Fix SQ/RQ drain logic Dan Carpenter
2019-10-25  8:16 ` Bernard Metzler
2019-10-25 12:34   ` Jason Gunthorpe [this message]

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=20191025123454.GH23952@ziepe.ca \
    --to=jgg@ziepe.ca \
    --cc=BMT@zurich.ibm.com \
    --cc=dan.carpenter@oracle.com \
    --cc=dledford@redhat.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