Re: [PATCH v1 1/3] IB/srp: Fix crash when unmapping data loop

2014-03-06 Thread Bart Van Assche
On 02/27/14 12:32, Sagi Grimberg wrote: As I recall (need to re-confirm this), the problem was that in unstable ports condition srp_abort is called invoking srp_free_req (unmap call #1) and reconnect process (or reset_device or terminate_io) finishes all requests in the request ring (unmap

[PATCH opensm] Revert Reset client reregistration when receiving handover

2014-03-06 Thread Hal Rosenstock
From: Alex Netes ale...@mellanox.com Date: Mon, 3 Dec 2012 14:45:24 +0200 This reverts commit f4722b0f833ed7a060f80b6757cfb9af78252678. This patch is no longer needed since first_master_sweep is now set when reaching MASTER state even if SM was in MASTER before. This is equivalent to the

RE: [PATCH opensm] Revert Reset client reregistration when receiving handover

2014-03-06 Thread Vladimir Koushnir
Regarding the comment in the reverted patch: - 3. set_client_rereg_on_sweep is TRUE. The one situation in which this - is true but first_time_master_sweep is FALSE is when the SM receives - a HANDOVER while in master. We don't want to re-setup everything by -

[PATCH opensm] osm_state_mgr.c: Remove redundant unset to first_time_master_sweep

2014-03-06 Thread Hal Rosenstock
From: Alex Netes ale...@mellanox.com Date: Thu, 18 Jul 2013 11:08:14 +0300 We should clear first_time_master_sweep anyway during the first sweep. Signed-off-by: Alex Netes ale...@mellanox.com --- opensm/osm_state_mgr.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git

Re: [PATCH 0/6] iser-target: Fix active I/O shutdown related issues

2014-03-06 Thread sagi grimberg
On 3/6/2014 12:04 AM, Nicholas A. Bellinger wrote: On Wed, 2014-03-05 at 14:12 +0200, Sagi Grimberg wrote: On 3/5/2014 2:06 AM, Nicholas A. Bellinger wrote: On Tue, 2014-03-04 at 17:17 +0200, Sagi Grimberg wrote: On 3/4/2014 2:00 AM, Nicholas A. Bellinger wrote: From: Nicholas Bellinger

Re: [PATCH] opensm/osm_sminfo_rcv.c: send trap144 to a newly found MASTER SM when in MASTER state

2014-03-06 Thread Hal Rosenstock
On 3/6/2014 8:01 AM, Alex Netes wrote: Before this patch, when SM in Master state finds other Master SM, it sends trap144 to previously found Master SM/SM with higher priority when it was in Discovering/Standby state. This can lead to wrong behaviour in a multi-SM topolgy: Setup: SM1 with

Re: [PATCH v1 1/3] IB/srp: Fix crash when unmapping data loop

2014-03-06 Thread sagi grimberg
On 3/6/2014 11:10 AM, Bart Van Assche wrote: On 02/27/14 12:32, Sagi Grimberg wrote: As I recall (need to re-confirm this), the problem was that in unstable ports condition srp_abort is called invoking srp_free_req (unmap call #1) and reconnect process (or reset_device or terminate_io)

Re: [PATCH v1 1/3] IB/srp: Fix crash when unmapping data loop

2014-03-06 Thread Sagi Grimberg
On 3/6/2014 5:32 PM, sagi grimberg wrote: On 3/6/2014 11:10 AM, Bart Van Assche wrote: On 02/27/14 12:32, Sagi Grimberg wrote: As I recall (need to re-confirm this), the problem was that in unstable ports condition srp_abort is called invoking srp_free_req (unmap call #1) and reconnect

RE: linux rdma 3.14 merge plans

2014-03-06 Thread Devesh Sharma
Hi Roland, Is it okay to send next series of patches even if previous series is not accepted yet in your tree? Off-course I will cut patches on top of previous series of patches. -Regards Devesh -Original Message- From: linux-rdma-ow...@vger.kernel.org

Re: [PATCHv3 net-next 00/31] Misc. fixes for cxgb4 and iw_cxgb4

2014-03-06 Thread Hariprasad S
On Wed, Mar 05, 2014 at 17:58:19 -0600, Steve Wise wrote: BTW, if you're frustrated from having to send these patches so many times because of changes being requested, this is the main reason why you shouldn't queue up such enormous numbers of patches at one time. Please try to