RE: [PATCH] iw_cxgb4: only call CQ completion handlers if they exist
Roland, this patch needs rework. As you pointed out to me, the iSER ULP never
arms the SCQ, so iw_cxgb4 should not be trying to notify. Thus even though
the patch below resolves the crash, it is not the correct fix.
I'll send a new patch that will key on whether the CQs are armed or not.
Steve.
-Original Message-
From: linux-rdma-ow...@vger.kernel.org
[mailto:linux-rdma-ow...@vger.kernel.org] On
Behalf Of Steve Wise
Sent: Tuesday, July 29, 2014 4:24 PM
To: rol...@kernel.org
Cc: linux-rdma@vger.kernel.org
Subject: [PATCH] iw_cxgb4: only call CQ completion handlers if they exist
The iser ULP creates a CQ without a SQ completion handler, which is valid.
This will cause iw_cxgb4 to crash the system if the QP is flushed.
The fix is to simply not call the handler if the handler ptr is NULL.
Signed-off-by: Steve Wise sw...@opengridcomputing.com
Cc: sta...@vger.kernel.org
---
drivers/infiniband/hw/cxgb4/qp.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb4/qp.c
b/drivers/infiniband/hw/cxgb4/qp.c
index 086f62f..bdbe6b4 100644
--- a/drivers/infiniband/hw/cxgb4/qp.c
+++ b/drivers/infiniband/hw/cxgb4/qp.c
@@ -1087,7 +1087,7 @@ static void __flush_qp(struct c4iw_qp *qhp, struct
c4iw_cq *rchp,
flushed = c4iw_flush_rq(qhp-wq, rchp-cq, count);
spin_unlock(qhp-lock);
spin_unlock_irqrestore(rchp-lock, flag);
- if (flushed) {
+ if (flushed rchp-ibcq.comp_handler) {
spin_lock_irqsave(rchp-comp_handler_lock, flag);
(*rchp-ibcq.comp_handler)(rchp-ibcq, rchp-ibcq.cq_context);
spin_unlock_irqrestore(rchp-comp_handler_lock, flag);
@@ -1101,7 +1101,7 @@ static void __flush_qp(struct c4iw_qp *qhp, struct
c4iw_cq *rchp,
flushed = c4iw_flush_sq(qhp);
spin_unlock(qhp-lock);
spin_unlock_irqrestore(schp-lock, flag);
- if (flushed) {
+ if (flushed schp-ibcq.comp_handler) {
spin_lock_irqsave(schp-comp_handler_lock, flag);
(*schp-ibcq.comp_handler)(schp-ibcq, schp-ibcq.cq_context);
spin_unlock_irqrestore(schp-comp_handler_lock, flag);
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Question on merge windows.
If that is the case would you like me to rebase the latest version of following patches onto your most recent for-next branch and resubmit? Or would you prefer I _not_ do so? I would like to see if we can get this series into 3.17 if possible. I'm guess the answer is no, but are there any changes to the patches if you rebase to 3.16-rc7? No changes. They all apply cleanly with git am to for-next. I don't see a list of patches staged for 3.17 in Roland's upstream tree yet, but he either may not have gotten to it yet, or just hasn't pushed them. Thanks for the reply, Ira -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [for-next 1/2] xprtrdma: take reference of rdma provider module
On Jul 22, 2014, at 1:06 AM, Devesh Sharma devesh.sha...@emulex.com wrote: -Original Message- From: Chuck Lever [mailto:chuck.le...@oracle.com] Sent: Monday, July 21, 2014 11:01 PM To: Devesh Sharma Cc: Steve Wise; Shirley Ma; Hefty, Sean; Roland Dreier; linux- r...@vger.kernel.org Subject: Re: [for-next 1/2] xprtrdma: take reference of rdma provider module On Jul 21, 2014, at 1:07 PM, Devesh Sharma devesh.sha...@emulex.com wrote: Until that support is in place, obviously I would prefer that the removal of the underlying driver be prevented while there are NFS mounts in place. I think that's what NFS users have come to expect. In other words, don't allow device removal until we have support for device insertion :-) This needs a fresh series of patches? do not allow removal would likely take an approach similar to what you originally posted, unless someone has an idea how to use a CM_EVENT to make this work, or there is an objection from the kernel RDMA folks. Okay, I will re-work the patch if need be. Devesh, if there isn’t one already, could you file an upstream bug at http://bugzilla.linux-nfs.org that documents the shutdown hang and perhaps summarizes this thread? Thanks! -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 08/21] xprtrdma: Back off rkey when FAST_REG_MR fails
Hey Roland, Sean and Hal.
We would like to submit this patch through the NFS tree, since the function
added to include/rdma/ib_verbs.h is only used for NFS over RDMA. Do any of you
have a problem with this patch, and can I have an acked-by if this is okay?
Thanks!
Anna
On 07/22/2014 10:52 AM, Chuck Lever wrote:
If posting a FAST_REG_MR Work Reqeust fails, revert the rkey update
to avoid subsequent IB_WC_MW_BIND_ERR completions.
Suggested-by: Steve Wise sw...@opengridcomputing.com
Signed-off-by: Chuck Lever chuck.le...@oracle.com
Tested-by: Shirley Ma shirley...@oracle.com
Tested-by: Devesh Sharma devesh.sha...@emulex.com
---
include/rdma/ib_verbs.h | 11 +++
net/sunrpc/xprtrdma/verbs.c | 12 +---
2 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index 7ccef34..c5c7ec6 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -2479,6 +2479,17 @@ static inline u32 ib_inc_rkey(u32 rkey)
}
/**
+ * ib_dec_rkey - decrements the key portion of the given rkey. Can be used
+ * when recovering from a local immediate error.
+ * @rkey - the rkey to decrement.
+ */
+static inline u32 ib_dec_rkey(u32 rkey)
+{
+ const u32 mask = 0x00ff;
+ return ((rkey - 1) mask) | (rkey ~mask);
+}
+
+/**
* ib_alloc_mw - Allocates a memory window.
* @pd: The protection domain associated with the memory window.
* @type: The type of the memory window (1 or 2).
diff --git a/net/sunrpc/xprtrdma/verbs.c b/net/sunrpc/xprtrdma/verbs.c
index 8bb7945..394b13f 100644
--- a/net/sunrpc/xprtrdma/verbs.c
+++ b/net/sunrpc/xprtrdma/verbs.c
@@ -1497,13 +1497,12 @@ rpcrdma_register_frmr_external(struct rpcrdma_mr_seg
*seg,
struct rpcrdma_frmr *frmr = mw-r.frmr;
struct ib_mr *mr = frmr-fr_mr;
struct ib_send_wr invalidate_wr, frmr_wr, *bad_wr, *post_wr;
-
- u8 key;
int len, pageoff;
int i, rc;
int seg_len;
u64 pa;
int page_no;
+ u32 rkey;
pageoff = offset_in_page(seg1-mr_offset);
seg1-mr_offset -= pageoff; /* start of page */
@@ -1558,14 +1557,11 @@ rpcrdma_register_frmr_external(struct rpcrdma_mr_seg
*seg,
rc = -EIO;
goto out_err;
}
-
- /* Bump the key */
- key = (u8)(mr-rkey 0x00FF);
- ib_update_fast_reg_key(mr, ++key);
-
frmr_wr.wr.fast_reg.access_flags = (writing ?
IB_ACCESS_REMOTE_WRITE | IB_ACCESS_LOCAL_WRITE :
IB_ACCESS_REMOTE_READ);
+ rkey = ib_inc_rkey(mr-rkey);
+ ib_update_fast_reg_key(mr, rkey);
frmr_wr.wr.fast_reg.rkey = mr-rkey;
DECR_CQCOUNT(r_xprt-rx_ep);
@@ -1574,6 +1570,8 @@ rpcrdma_register_frmr_external(struct rpcrdma_mr_seg
*seg,
if (rc) {
dprintk(RPC: %s: failed ib_post_send for register,
status %i\n, __func__, rc);
+ rkey = ib_dec_rkey(mr-rkey);
+ ib_update_fast_reg_key(mr, rkey);
goto out_err;
} else {
seg1-mr_rkey = mr-rkey;
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Very Urgent............
Greetings from gulf region Thanks for the e-mail. I am very interested on funding lucrative business partnership with you acting as the manager and sole controller of the investment while i remain a silent investor for a period of ten yrs , though I am only looking at investment opportunities within the range you specified for a start. You can reply me here (fmoris...@yahoo.com) Let me know your thought asap Regards Financial Consultant Mr.Fabian Morision -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [for-next 1/2] xprtrdma: take reference of rdma provider module
-Original Message- From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma- ow...@vger.kernel.org] On Behalf Of Chuck Lever Sent: Thursday, July 31, 2014 12:09 AM To: Devesh Sharma Cc: Steve Wise; Shirley Ma; Hefty, Sean; Roland Dreier; linux- r...@vger.kernel.org Subject: Re: [for-next 1/2] xprtrdma: take reference of rdma provider module On Jul 22, 2014, at 1:06 AM, Devesh Sharma devesh.sha...@emulex.com wrote: -Original Message- From: Chuck Lever [mailto:chuck.le...@oracle.com] Sent: Monday, July 21, 2014 11:01 PM To: Devesh Sharma Cc: Steve Wise; Shirley Ma; Hefty, Sean; Roland Dreier; linux- r...@vger.kernel.org Subject: Re: [for-next 1/2] xprtrdma: take reference of rdma provider module On Jul 21, 2014, at 1:07 PM, Devesh Sharma devesh.sha...@emulex.com wrote: Until that support is in place, obviously I would prefer that the removal of the underlying driver be prevented while there are NFS mounts in place. I think that's what NFS users have come to expect. In other words, don't allow device removal until we have support for device insertion :-) This needs a fresh series of patches? do not allow removal would likely take an approach similar to what you originally posted, unless someone has an idea how to use a CM_EVENT to make this work, or there is an objection from the kernel RDMA folks. Okay, I will re-work the patch if need be. Devesh, if there isn't one already, could you file an upstream bug at http://bugzilla.linux-nfs.org that documents the shutdown hang and perhaps summarizes this thread? Thanks! A bug has been filed https://bugzilla.linux-nfs.org/show_bug.cgi?id=266 -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
