public inbox for linux-rdma@vger.kernel.org
 help / color / mirror / Atom feed
From: Bernd Schubert <bernd.schubert-mPn0NPGs4xGatNDF+KUbs4QuADTiUCJX@public.gmane.org>
To: "Hefty, Sean" <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: "linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"roland-BHEL68pLQRGGvPXPguhicg@public.gmane.org"
	<roland-BHEL68pLQRGGvPXPguhicg@public.gmane.org>,
	Sven Breuner
	<sven.breuner-mPn0NPGs4xGatNDF+KUbs4QuADTiUCJX@public.gmane.org>
Subject: Re: [PATCH] core/verb.c: fix kernel panic: always initialize struct ib_qp *qp->usecnt
Date: Fri, 20 Jan 2012 17:14:46 +0100	[thread overview]
Message-ID: <4F1992F6.9070103@itwm.fraunhofer.de> (raw)
In-Reply-To: <1828884A29C6694DAF28B7E6B8A823732DC0C33E-P5GAC/sN6hlZtRGVdHMbwrfspsVTdybXVpNB7YpNyf8@public.gmane.org>

Hmm, I think we do have serious problem with the hole approach. While 
the patch works for the kernel side, there is a problem with user space 
libraries. So I monitored our daemons and noticed ibv_destroy_cq() 
failed. The reason again seems to be the same issue as already fixed for 
kernel qp's. So in __ibv_create_qp() (libibverbs/src/verbs.c):

> __ibv_create_qp()

> 	struct ibv_qp *qp = pd->context->ops.create_qp(pd, qp_init_attr);
>
> 	if (qp) {
> 		qp->context    	     = pd->context;
> 		qp->qp_context 	     = qp_init_attr->qp_context;
> 		qp->pd         	     = pd;
> 		qp->send_cq    	     = qp_init_attr->send_cq;
[...]

I *guess* the qp allocated by pd->context->ops.create_qp() does not have 
qp->usecnt initialized (not does it know anything about it). So its 
random value will fail the destruction later. A simple workaround that 
would work for us, is to extend the patch I send to

diff --git a/drivers/infiniband/core/verbs.c 
b/drivers/infiniband/core/verbs.c
index 602b1bd..fba1675 100644
--- a/drivers/infiniband/core/verbs.c
+++ b/drivers/infiniband/core/verbs.c
@@ -874,7 +874,7 @@ int ib_destroy_qp(struct ib_qp *qp)
         struct ib_srq *srq;
         int ret;

-       if (atomic_read(&qp->usecnt))
+       if (qp->qp_type == IB_QPT_XRC_TGT && atomic_read(&qp->usecnt))
                 return -EBUSY;

         if (qp->real_qp != qp)



However, what is is with user space setting type to IB_QPT_XRC_TGT? I 
guess this could be solved by letting the kernel zero the memory 
returned by ->ops.create_qp(pd, qp_init_attr).
Btw, I didn't figure out yet, how this translates at all in kernel 
space? Is this op directly going to the device driver?

But even if we are properly going to initialize the qp, what is with 
user space mischievously trying to crash the system by manipulating 
struct ib_qp *qp?


Thanks,
Bernd


--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2012-01-20 16:14 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-19 19:46 [PATCH] core/verb.c: fix kernel panic: always initialize struct ib_qp *qp->usecnt Bernd Schubert
     [not found] ` <20120119194641.1391553.39048.stgit-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2012-01-19 20:29   ` Hefty, Sean
     [not found]     ` <1828884A29C6694DAF28B7E6B8A823732DC0C33E-P5GAC/sN6hlZtRGVdHMbwrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2012-01-20 16:14       ` Bernd Schubert [this message]
     [not found]         ` <4F1992F6.9070103-mPn0NPGs4xGatNDF+KUbs4QuADTiUCJX@public.gmane.org>
2012-01-20 18:40           ` Roland Dreier
     [not found]             ` <CAL1RGDWSh3HpVY5dui549EoqhzTYaSnsCPGdEU+hPZ9NWx6ttw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-01-20 18:43               ` Roland Dreier
     [not found]                 ` <CAL1RGDW=XfCd3aCmB0mE1WcOUeDj=17=s2K0A3zpFmBF6Rg_Rg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-01-27 16:23                   ` Sven Breuner
     [not found]                     ` <4F22CF82.2060606-mPn0NPGs4xGatNDF+KUbs4QuADTiUCJX@public.gmane.org>
2012-01-27 17:20                       ` Roland Dreier
     [not found]                         ` <CAL1RGDXXYG48d2P0h4G+z4W8HebjrQ7HTWyx5FqgB0_2OqC4Ng-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-01-27 18:49                           ` Sven Breuner
     [not found]                             ` <4F22F1C9.3090801-mPn0NPGs4xGatNDF+KUbs4QuADTiUCJX@public.gmane.org>
2012-01-27 19:09                               ` Roland Dreier
2012-01-23 15:11               ` Bernd Schubert
2012-01-19 20:38   ` Greg KH
  -- strict thread matches above, loose matches on Subject: below --
2012-01-20 18:43 Hefty, Sean
     [not found] ` <1828884A29C6694DAF28B7E6B8A823732DC115E2-P5GAC/sN6hmkrb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
2012-01-23 16:11   ` Bernd Schubert

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=4F1992F6.9070103@itwm.fraunhofer.de \
    --to=bernd.schubert-mpn0npgs4xgatndf+kubs4quadtiucjx@public.gmane.org \
    --cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=roland-BHEL68pLQRGGvPXPguhicg@public.gmane.org \
    --cc=sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=sven.breuner-mPn0NPGs4xGatNDF+KUbs4QuADTiUCJX@public.gmane.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