[Bug 48891] scsi/lpfc/lpfc_ct.c:637: possible finger trouble ?

2013-01-02 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=48891


Alan a...@lxorguk.ukuu.org.uk changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||CODE_FIX




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 0/2] RESEND Add support for new IBM SAS controllers

2013-01-02 Thread wenxiong
I am re-sending blk iopoll support and bump version patches in previous 
series.

Thanks for your help!
Wendy
-- 
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 2/2] RESEND ipr: Driver version 2.6.0

2013-01-02 Thread wenxiong
Bump driver version.

Signed-off-by: Wen Xiong wenxi...@linux.vnet.ibm.com
---
 drivers/scsi/ipr.h |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: b/drivers/scsi/ipr.h
===
--- a/drivers/scsi/ipr.h2013-01-02 10:52:20.183729214 -0600
+++ b/drivers/scsi/ipr.h2013-01-02 10:53:45.793719329 -0600
@@ -39,8 +39,8 @@
 /*
  * Literals
  */
-#define IPR_DRIVER_VERSION 2.5.4
-#define IPR_DRIVER_DATE (July 11, 2012)
+#define IPR_DRIVER_VERSION 2.6.0
+#define IPR_DRIVER_DATE (November 16, 2012)
 
 /*
  * IPR_MAX_CMD_PER_LUN: This defines the maximum number of outstanding

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


Re: [PATCH 0/2] RESEND Add support for new IBM SAS controllers

2013-01-02 Thread Bart Van Assche

On 01/02/13 19:23, wenxi...@linux.vnet.ibm.com wrote:

I am re-sending blk iopoll support and bump version patches in previous 
series.


Hello Wendy,

How much do these patches improve the performance of the ipr driver ?

Thanks,

Bart.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 0/5] target task management fixes and cleanups

2013-01-02 Thread Roland Dreier
From: Roland Dreier rol...@purestorage.com

Hi Nic,

A few fixes for TMR handling (fix crashes when a backend is really
slow, fix a reference leak if we get a TMR for a non-existent LUN) and
a couple of trivial cleanups in related code.

Roland Dreier (5):
  target: Don't let abort handling free pending write commands too soon
  target: Fix use-after-free in LUN RESET handling
  target: Release se_cmd when LUN lookup fails for TMR
  target: Remove useless if statement
  target: Remove never-used TMR_FABRIC_TMR enum value

 drivers/target/target_core_tmr.c   | 12 
 drivers/target/target_core_transport.c |  8 +---
 include/target/target_core_base.h  |  1 -
 3 files changed, 5 insertions(+), 16 deletions(-)

-- 
1.8.0

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


[PATCH 3/5] target: Release se_cmd when LUN lookup fails for TMR

2013-01-02 Thread Roland Dreier
From: Roland Dreier rol...@purestorage.com

When transport_lookup_tmr_lun() fails and we return a task management
response from target_complete_tmr_failure(), we need to call
transport_cmd_check_stop_to_fabric() to release the last ref to the
cmd after calling se_tfo-queue_tm_rsp(), or else we will never remove
the failed TMR from the session command list (and we'll end up waiting
forever when trying to tear down the session).

Signed-off-by: Roland Dreier rol...@purestorage.com
---
 drivers/target/target_core_transport.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/target/target_core_transport.c 
b/drivers/target/target_core_transport.c
index 49390d8..fe6208f 100644
--- a/drivers/target/target_core_transport.c
+++ b/drivers/target/target_core_transport.c
@@ -1393,6 +1393,8 @@ static void target_complete_tmr_failure(struct 
work_struct *work)
 
se_cmd-se_tmr_req-response = TMR_LUN_DOES_NOT_EXIST;
se_cmd-se_tfo-queue_tm_rsp(se_cmd);
+
+   transport_cmd_check_stop_to_fabric(cmd);
 }
 
 /**
-- 
1.8.0

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


[PATCH 1/5] target: Don't let abort handling free pending write commands too soon

2013-01-02 Thread Roland Dreier
From: Roland Dreier rol...@purestorage.com

The following sequence happens for write commands (or any other
commands with a data out phase):

 - The transport calls target_submit_cmd(), which sets CMD_T_ACTIVE in
   cmd-transport_state and sets cmd-t_state to TRANSPORT_NEW_CMD.
 - Things go on transport_generic_new_cmd(), which notices that the
   command needs to transfer data, so it sets cmd-t_state to
   TRANSPORT_WRITE_PENDING and calls transport_cmd_check_stop().
 - transport_cmd_check_stop() clears CMD_T_ACTIVE in cmd-transport_state
   and returns in the normal case.
 - Then we continue on to call -se_tfo-write_pending().
 - The data comes back from the initiator, and the transport calls
   target_execute_cmd(), which sets cmd-t_state to TRANSPORT_PROCESSING
   and calls into the backend to actually write the data.

At this point, the backend might take a long time to complete the
command, since it has to do real IO.  If an abort request comes in for
this command at this point, it will not wait for the command to finish
since CMD_T_ACTIVE is not set.  Then when the command does finally
finish, we blow up with use-after-free.

Avoid this by setting CMD_T_ACTIVE in target_execute_cmd() so that
transport_wait_for_tasks() waits for the command to finish executing.
This matches the behavior from before commit 1389533ef944 (target:
remove transport_generic_handle_data), when data was signaled via
transport_generic_handle_data(), which set CMD_T_ACTIVE because it
called transport_add_cmd_to_queue().

Signed-off-by: Roland Dreier rol...@purestorage.com
---
 drivers/target/target_core_transport.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/target/target_core_transport.c 
b/drivers/target/target_core_transport.c
index c23c76c..1dd9d66 100644
--- a/drivers/target/target_core_transport.c
+++ b/drivers/target/target_core_transport.c
@@ -1688,6 +1688,7 @@ void target_execute_cmd(struct se_cmd *cmd)
}
 
cmd-t_state = TRANSPORT_PROCESSING;
+   cmd-transport_state |= CMD_T_ACTIVE;
spin_unlock_irq(cmd-t_state_lock);
 
if (!target_handle_task_attr(cmd))
-- 
1.8.0

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


[PATCH 5/5] target: Remove never-used TMR_FABRIC_TMR enum value

2013-01-02 Thread Roland Dreier
From: Roland Dreier rol...@purestorage.com

Signed-off-by: Roland Dreier rol...@purestorage.com
---
 include/target/target_core_base.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/target/target_core_base.h 
b/include/target/target_core_base.h
index 7cae236..02ed017 100644
--- a/include/target/target_core_base.h
+++ b/include/target/target_core_base.h
@@ -210,7 +210,6 @@ enum tcm_tmreq_table {
TMR_LUN_RESET   = 5,
TMR_TARGET_WARM_RESET   = 6,
TMR_TARGET_COLD_RESET   = 7,
-   TMR_FABRIC_TMR  = 255,
 };
 
 /* fabric independent task management response values */
-- 
1.8.0

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


[PATCH 4/5] target: Remove useless if statement

2013-01-02 Thread Roland Dreier
From: Roland Dreier rol...@purestorage.com

We do the same thing no matter which way the test goes, so just remove
the test and do what we're going to do.

The debug messages printed the wrong value of CMD_T_ACTIVE and don't
seem particularly useful, remove them too.

Signed-off-by: Roland Dreier rol...@purestorage.com
---
 drivers/target/target_core_tmr.c | 12 
 1 file changed, 12 deletions(-)

diff --git a/drivers/target/target_core_tmr.c b/drivers/target/target_core_tmr.c
index c6e0293..d0b4dd9 100644
--- a/drivers/target/target_core_tmr.c
+++ b/drivers/target/target_core_tmr.c
@@ -331,18 +331,6 @@ static void core_tmr_drain_state_list(
 
fe_count = atomic_read(cmd-t_fe_count);
 
-   if (!(cmd-transport_state  CMD_T_ACTIVE)) {
-   pr_debug(LUN_RESET: got CMD_T_ACTIVE for
-cdb: %p, t_fe_count: %d dev: %p\n, cmd,
-   fe_count, dev);
-   cmd-transport_state |= CMD_T_ABORTED;
-   spin_unlock_irqrestore(cmd-t_state_lock, flags);
-
-   core_tmr_handle_tas_abort(tmr_nacl, cmd, tas, fe_count);
-   continue;
-   }
-   pr_debug(LUN_RESET: Got !CMD_T_ACTIVE for cdb: %p,
-t_fe_count: %d dev: %p\n, cmd, fe_count, dev);
cmd-transport_state |= CMD_T_ABORTED;
spin_unlock_irqrestore(cmd-t_state_lock, flags);
 
-- 
1.8.0

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


[PATCH 0/1] Fix several unlock issues in ipr driver

2013-01-02 Thread wenxiong
The patch fixed several unlock issues in ipr driver.

Thanks,
Wendy
-- 
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/1] ipr: Fix several unlock issues in ipr driver

2013-01-02 Thread Brian King
On 01/02/2013 04:26 PM, wenxi...@linux.vnet.ibm.com wrote:
 This patch fixes several unlock issues in ipr driver.

James - this fixes a couple regressions that were introduced in
the previous patch set.

Acked-by: Brian King brk...@linux.vnet.ibm.com


-- 
Brian King
Power Linux I/O
IBM Linux Technology Center


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


Re: [PATCH 1/2] RESEND ipr: Implement block iopoll

2013-01-02 Thread Brian King
This should probably have been flagged with a v2 rather than a RESEND since
it has been changed to use kstrtoul.

Acked-by: Brian King brk...@linux.vnet.ibm.com

-- 
Brian King
Power Linux I/O
IBM Linux Technology Center


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


Re: [scsi:for-next 11/19] drivers/scsi/ipr.c:8700:16: warning: array subscript is above array bounds

2013-01-02 Thread wenxiong

Hi Fengguang,

We built 32bit kernel for current jejb for-next tree on x86 platform  
by using your config file. Seems We couldn't reproduce the error in  
our environment. What options you use to make 32bit kernel? We used:


make ARCH=i386 V=1 -Wall.

Also can you reproduce this with current jejb for-next tree in your  
environment?


Thanks,
Wendy

Quoting kbuild test robot fengguang...@intel.com:


tree:   git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git for-next
head:   7ff768a5feade4fa51f038d97b7eb9f72152b7c1
commit: 7af0de314b738e26bf4d49a6f30d00ce56343107 [11/19] [SCSI] ipr:  
Add support for MSI-X and distributed completion

config: i386-randconfig-x243 (attached as .config)

All warnings:

drivers/scsi/ipr.c: In function 'ipr_probe':
drivers/scsi/ipr.c:8700:16: warning: array subscript is above array  
bounds [-Warray-bounds]


vim +8700 drivers/scsi/ipr.c

7af0de31 wenxi...@linux.vnet.ibm.com 2012-12-03  8684   
ioa_cfg-hrrq[i].min_cmd_id =
7af0de31 wenxi...@linux.vnet.ibm.com 2012-12-03  8685   
	IPR_NUM_INTERNAL_CMD_BLKS +
7af0de31 wenxi...@linux.vnet.ibm.com 2012-12-03  8686  	(i - 1)  
* entries_each_hrrq;
7af0de31 wenxi...@linux.vnet.ibm.com 2012-12-03  8687   
ioa_cfg-hrrq[i].max_cmd_id =
7af0de31 wenxi...@linux.vnet.ibm.com 2012-12-03  8688   
	(IPR_NUM_INTERNAL_CMD_BLKS +
7af0de31 wenxi...@linux.vnet.ibm.com 2012-12-03  8689  	i *  
entries_each_hrrq - 1);

7af0de31 wenxi...@linux.vnet.ibm.com 2012-12-03  8690   }
7af0de31 wenxi...@linux.vnet.ibm.com 2012-12-03  8691   } else {
7af0de31 wenxi...@linux.vnet.ibm.com 2012-12-03  8692   
			entries_each_hrrq = IPR_NUM_CMD_BLKS;
7af0de31 wenxi...@linux.vnet.ibm.com 2012-12-03  8693   
			ioa_cfg-hrrq[i].min_cmd_id = 0;
7af0de31 wenxi...@linux.vnet.ibm.com 2012-12-03  8694   
			ioa_cfg-hrrq[i].max_cmd_id = (entries_each_hrrq - 1);

7af0de31 wenxi...@linux.vnet.ibm.com 2012-12-03  8695   }
7af0de31 wenxi...@linux.vnet.ibm.com 2012-12-03  8696   
		ioa_cfg-hrrq[i].size = entries_each_hrrq;

7af0de31 wenxi...@linux.vnet.ibm.com 2012-12-03  8697   }
7af0de31 wenxi...@linux.vnet.ibm.com 2012-12-03  8698
7af0de31 wenxi...@linux.vnet.ibm.com 2012-12-03  8699  	i =  
IPR_NUM_CMD_BLKS -
7af0de31 wenxi...@linux.vnet.ibm.com 2012-12-03 @8700   
		ioa_cfg-hrrq[ioa_cfg-hrrq_num - 1].max_cmd_id - 1;

7af0de31 wenxi...@linux.vnet.ibm.com 2012-12-03  8701   if (i  0) {
7af0de31 wenxi...@linux.vnet.ibm.com 2012-12-03  8702   
		ioa_cfg-hrrq[ioa_cfg-hrrq_num - 1].size += i;
7af0de31 wenxi...@linux.vnet.ibm.com 2012-12-03  8703   
		ioa_cfg-hrrq[ioa_cfg-hrrq_num - 1].max_cmd_id += i;

7af0de31 wenxi...@linux.vnet.ibm.com 2012-12-03  8704   }
7af0de31 wenxi...@linux.vnet.ibm.com 2012-12-03  8705
^1da177e Linus Torvalds  2005-04-16  8706  	for (i = 0;  
i  IPR_NUM_CMD_BLKS; i++) {
203fa3fe Kleber Sacilotto de Souza   2012-08-22  8707  		ipr_cmd =  
pci_pool_alloc(ioa_cfg-ipr_cmd_pool, GFP_KERNEL, dma_addr);

^1da177e Linus Torvalds  2005-04-16  8708

---
0-DAY kernel build testing backend Open Source Technology Center
Fengguang Wu, Yuanhan Liu  Intel Corporation




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