Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1421957 > unrolled thread

Re: [PATCH 4/5] nvmet-rdma: add a NVMe over Fabrics RDMA target driver

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 4/5] nvmet-rdma: add a NVMe over Fabrics RDMA target  driver Christoph Hellwig <hch@infradead.org> - 2016-06-14 16:40 +0200
    RE: [PATCH 4/5] nvmet-rdma: add a NVMe over Fabrics RDMA target driver "Steve Wise" <swise@opengridcomputing.com> - 2016-06-14 17:20 +0200
    RE: [PATCH 4/5] nvmet-rdma: add a NVMe over Fabrics RDMA target driver "Steve Wise" <swise@opengridcomputing.com> - 2016-06-14 17:30 +0200

#1421957 — Re: [PATCH 4/5] nvmet-rdma: add a NVMe over Fabrics RDMA target driver

On Thu, Jun 09, 2016 at 06:03:51PM -0500, Steve Wise wrote:
> The above nvmet cm event handler, nvmet_rdma_cm_handler(), calls
> nvmet_rdma_queue_connect() for CONNECT_REQUEST events, which calls
> nvmet_rdma_alloc_queue (), which, if it encounters a failure (like creating
> the qp), calls nvmet_rdma_cm_reject () which calls rdma_reject().  The
> non-zero error, however, gets returned back here and this function returns
> the error to the RDMA_CM which will also reject the connection as well as
> destroy the cm_id.  So there are two rejects happening, I think.  Either
> nvmet should reject and destroy the cm_id, or it should do neither and
> return non-zero to the RDMA_CM to reject/destroy.

Can you just send a patch?

[toc] | [next] | [standalone]

#1422004 — RE: [PATCH 4/5] nvmet-rdma: add a NVMe over Fabrics RDMA target driver

> On Thu, Jun 09, 2016 at 06:03:51PM -0500, Steve Wise wrote:
> > The above nvmet cm event handler, nvmet_rdma_cm_handler(), calls
> > nvmet_rdma_queue_connect() for CONNECT_REQUEST events, which calls
> > nvmet_rdma_alloc_queue (), which, if it encounters a failure (like creating
> > the qp), calls nvmet_rdma_cm_reject () which calls rdma_reject().  The
> > non-zero error, however, gets returned back here and this function returns
> > the error to the RDMA_CM which will also reject the connection as well as
> > destroy the cm_id.  So there are two rejects happening, I think.  Either
> > nvmet should reject and destroy the cm_id, or it should do neither and
> > return non-zero to the RDMA_CM to reject/destroy.
> 
> Can you just send a patch?

Yes, I'll send it out in a separate email.

[toc] | [prev] | [next] | [standalone]

#1422015 — RE: [PATCH 4/5] nvmet-rdma: add a NVMe over Fabrics RDMA target driver

> Either
> > > nvmet should reject and destroy the cm_id, or it should do neither and
> > > return non-zero to the RDMA_CM to reject/destroy.
> >
> > Can you just send a patch?
> 
> Yes, I'll send it out in a separate email.

Before I do, what do you think of this (untested)?

diff --git a/drivers/nvme/target/rdma.c b/drivers/nvme/target/rdma.c
index b1c6e5b..6f0c335 100644
--- a/drivers/nvme/target/rdma.c
+++ b/drivers/nvme/target/rdma.c
@@ -1255,7 +1255,8 @@ static int nvmet_rdma_cm_handler(struct rdma_cm_id *cm_id,

        switch (event->event) {
        case RDMA_CM_EVENT_CONNECT_REQUEST:
-               ret = nvmet_rdma_queue_connect(cm_id, event);
+               if (nvmet_rdma_queue_connect(cm_id, event))
+                       rdma_destroy_id(cm_id);
                break;
        case RDMA_CM_EVENT_ESTABLISHED:
                nvmet_rdma_queue_established(queue);

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web