Re: [RFC-v2 10/12] iser-target: Add logic for verbs
On 23/03/2013 01:55, Nicholas A. Bellinger wrote: +++ b/drivers/infiniband/ulp/isert/isert_verbs.h @@ -0,0 +1,5 @@ +extern void isert_connect_release(struct isert_conn *); +extern void isert_put_conn(struct isert_conn *); +extern int isert_cma_handler(struct rdma_cm_id *, struct rdma_cm_event *); +extern int isert_post_recv(struct isert_conn *, u32); +extern int isert_post_send(struct isert_conn *, struct iser_tx_desc *); why use extern here? maybe a left over from V1? -- 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] scsi_dh_alua: Add module parameter to allow failover to non preferred path without STPG
How about the following? Reworded in a way such that 0 means no and 1 means
yes.
+static uint optimize_stpg;
+module_param(optimize_stpg, uint, S_IRUGO|S_IWUSR);
+MODULE_PARM_DESC(optimize_stpg, "Allow use of a non-optimized path, rather
than sending a STPG, when implicit TPGS is supported (0=No,1=Yes). Default is
0.");
Thanks,
Sean Stewart
-Original Message-
From: Ewan Milne [mailto:emi...@redhat.com]
Sent: Monday, April 01, 2013 9:25 AM
To: Stewart, Sean
Cc: linux-scsi@vger.kernel.org; dm-de...@redhat.com; james.bottom...@suse.de;
snit...@redhat.com; h...@suse.de
Subject: Re: [PATCH] scsi_dh_alua: Add module parameter to allow failover to
non preferred path without STPG
On Thu, 2013-03-28 at 22:07 +, Stewart, Sean wrote:
> +static uint optimize_stpg;
> +module_param(optimize_stpg, uint, S_IRUGO|S_IWUSR);
> +MODULE_PARM_DESC(optimize_stpg, "Send STPG command for Failover on
> +non-preferred path(0=Yes,1=No). Default is 0.");
Could you possibly reword the description? When I first read this, it seemed
backwards to have 0=Yes and 1=No.
-Ewan D. Milne
N�r��yb�X��ǧv�^�){.n�+{���"�{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj"��!�i
Re: [PATCH] scsi_transport_fc: Make 'port_state' writeable
On 3/18/2013 3:09 AM, Hannes Reinecke wrote: On 03/15/2013 08:13 PM, Bart Van Assche wrote: On 03/15/13 19:51, Mike Christie wrote: On 03/15/2013 08:41 AM, Bart Van Assche wrote: How about using the value of scsi_cmnd.jiffies_at_alloc to finish only those SCSI commands in the host reset handler that exceeded a certain processing time ? We basically do this now. When a scsi command times out the scsi layer blocks the host from processing new commands and waits for all outstanding commands to either finish normally or timeout. When all commands have finished or timedout, then we start the scsi eh code. So, by the time we have go to the scsi eh callbacks we are in a state where all the commands being processed by the eh have exceeded a certain processing time. If you mean you want to drop the block and wait part, then I think it could speed things up to do the abort callbacks while other IO is running (as long as the driver can support it). However if the abort fails and you need to escalate to operations like resets which interfere with multiple commands, then the driver/scsi-ml does not have much choice in what it does cleanup wise. There would be no point in checking the jiffies_at_alloc. The commands that are going to be affected by the tmf or host reset operation must be returned to the scsi-ml for retries or failure upwards. Hello Mike, It seems like there is a misunderstanding. With my comment I was not referring to the SCSI ML but to the SCSI LLD. LLD drivers like ib_srp keep track of outstanding SCSI requests. With the SRP protocol it is possible to tell the InfiniBand HCA not to deliver completions for outstanding requests by closing the connection used for SRP communication. Hence my suggestion to finish SCSI commands that were queued longer than a certain time ago from inside the LLD host reset handler. I'm not sure though whether all types of FC HBA's allow something equivalent. Well, this is not quite identical to what I've been trying to achieve with this patch. This patch is for an individual rport which has gone out to lunch. Sure we could down the link from the HBA, but that would terminate I/O to _all_ connected rports, not just the malfunctioning one. So that wouldn't help us here. The closest equivalent to that would be a port logout; however, as discussed in the I_T nexus reset thread we would need another callout to the LLDs here as this definitely needs LLD support and none of the current LLDs have it implemented. Cheers, Hannes I think lpfc survives your rport state change as : part of the lld behavior on the callback, to clean up reference counts, is to abort all i/o that is outstanding to the rport. So the ref checking not only protects lpfc from prematurely freeing a structure (my real concern), but also just happens to abort all i/o. We got lucky. I still believe the I_T_nexus reset is the right way to solve this. -- james s -- 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] scsi_transport_fc: Make 'port_state' writeable
Hannes, I'm finally going through this thread. I'm a bit uncomfortable about making the rport state writeable. The rport state is tightly tied to the driver's discovery engine, and I'm concerned about some of the callbacks firing, such as the rport_delete(), and the driver taking an action that isn't legit as the driver wasn't the one that called the fc_remote_port_delete() call. I expect, at least in the lpfc driver, we would require a change to work with this. Although, we had to add an ugly internal reference counter mechanism so we didn't actually early-free structures, that may have saved your changing of this. -- james s On 3/15/2013 7:55 AM, Hannes Reinecke wrote: On 03/14/2013 07:09 PM, Steffen Maier wrote: Just for my understanding: So this is a bit like writing 0 into the failed attribute of a zfcp_port in sysfs (zfcp_sysfs_port_failed_store()) which forces a port reopen recovery including a sequence of fc_remote_port_delete and fc_remote_port_add? Sorta. This patch simulates the result of an RSCN where this remote port is missing. So the fast_io_fail / dev_loss_tmo mechanism is triggered (until further notice). It'll be reset with the next RSCN or by manually resetting the port state. If so, it sounds good to have this functionality for any FC LLD in common code. That's why I posted this code :-) Rationale for this patch is a weird test case with brocade switches; there you can actually disable a _target_ port. So the port isn't reachable anymore but no RSCN is send. And the LLDD is forced into error recovery which'll take _ages_ as each and every command send during error recovery will time out. (And I can think about deprecating parts of zfcp code, next we could consider the same for zfcp's forced LUN and adapter recovery or maybe this already exists as sdev's writable state attribute and the adapter recovery can be performed manually by walking all fc_rports writing their port_state.) I don't think the sdev 'state' attribute is useable here; it doesn't trigger a rediscovery. You'd want to use 'rescan' here. But yeah, that would be one of the goals. Still waiting for some response to the patch, though. Testing has been successful on our side, plus I've posted a patchset for multipath-tools utilizing this patch. So it would be good if it could be included. James? Cheers, Hannes -- 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
fcoe pull-request 3.9-rc5
The following changes since commit 8bb9660418e05bb1845ac1a2428444d78e322cc7:
Linux 3.9-rc4 (2013-03-23 16:52:44 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/rwlove/fcoe.git
tags/for-3.9-rc
for you to fetch changes up to 0db0e377ab5be5d507a2fca3d78215cd2e83b974:
libfcoe: Fix fcoe_sysfs VN2VN mode (2013-03-25 16:04:22 -0700)
Critical patches to fix FCoE VN2VN mode with new interfaces targeting 3.9-rc
Robert Love (5):
bnx2fc: Make the fcoe_cltr the SCSI host parent
fcoe: Fix deadlock between create and destroy paths
libfc, fcoe, bnx2fc: Always use fcoe_disc_init for discovery
layer initialization
libfc, fcoe, bnx2fc: Split fc_disc_init into fc_disc_{init, config}
libfcoe: Fix fcoe_sysfs VN2VN mode
drivers/scsi/bnx2fc/bnx2fc_fcoe.c |6 ++--
drivers/scsi/fcoe/fcoe.c | 15 +++---
drivers/scsi/fcoe/fcoe_ctlr.c | 60
-
drivers/scsi/libfc/fc_disc.c | 26 +++-
include/scsi/libfc.h |3 +-
5 files changed, 80 insertions(+), 30 deletions(-)
--
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] ibmvscsi: Fix slave_configure deadlock
* Brian King (brk...@linux.vnet.ibm.com) wrote: > > No locks should be held when calling scsi_adjust_queue_depth > so drop the lock in slave_configure prior to calling it. > > Signed-off-by: Brian King Acked-by: Robert Jennings > --- > > drivers/scsi/ibmvscsi/ibmvscsi.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff -puN drivers/scsi/ibmvscsi/ibmvscsi.c~ibmvscsi_slave_configure_deadlock > drivers/scsi/ibmvscsi/ibmvscsi.c > --- linux/drivers/scsi/ibmvscsi/ibmvscsi.c~ibmvscsi_slave_configure_deadlock > 2013-03-06 16:36:26.0 -0600 > +++ linux-bjking1/drivers/scsi/ibmvscsi/ibmvscsi.c2013-03-06 > 16:36:26.0 -0600 > @@ -1899,8 +1899,8 @@ static int ibmvscsi_slave_configure(stru > sdev->allow_restart = 1; > blk_queue_rq_timeout(sdev->request_queue, 120 * HZ); > } > - scsi_adjust_queue_depth(sdev, 0, shost->cmd_per_lun); > spin_unlock_irqrestore(shost->host_lock, lock_flags); > + scsi_adjust_queue_depth(sdev, 0, shost->cmd_per_lun); > return 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/1] ibmvscsi: Fix slave_configure deadlock
No locks should be held when calling scsi_adjust_queue_depth so drop the lock in slave_configure prior to calling it. Signed-off-by: Brian King --- drivers/scsi/ibmvscsi/ibmvscsi.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/scsi/ibmvscsi/ibmvscsi.c~ibmvscsi_slave_configure_deadlock drivers/scsi/ibmvscsi/ibmvscsi.c --- linux/drivers/scsi/ibmvscsi/ibmvscsi.c~ibmvscsi_slave_configure_deadlock 2013-03-06 16:36:26.0 -0600 +++ linux-bjking1/drivers/scsi/ibmvscsi/ibmvscsi.c 2013-03-06 16:36:26.0 -0600 @@ -1899,8 +1899,8 @@ static int ibmvscsi_slave_configure(stru sdev->allow_restart = 1; blk_queue_rq_timeout(sdev->request_queue, 120 * HZ); } - scsi_adjust_queue_depth(sdev, 0, shost->cmd_per_lun); spin_unlock_irqrestore(shost->host_lock, lock_flags); + scsi_adjust_queue_depth(sdev, 0, shost->cmd_per_lun); return 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
Re: [PATCH] scsi_dh_alua: Add module parameter to allow failover to non preferred path without STPG
On Thu, 2013-03-28 at 22:07 +, Stewart, Sean wrote: > +static uint optimize_stpg; > +module_param(optimize_stpg, uint, S_IRUGO|S_IWUSR); > +MODULE_PARM_DESC(optimize_stpg, "Send STPG command for Failover on > non-preferred path(0=Yes,1=No). Default is 0."); Could you possibly reword the description? When I first read this, it seemed backwards to have 0=Yes and 1=No. -Ewan D. Milne -- 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
