FC pass-through support for zfcp
Subsystems (3)
cover FC pass-through support for zfcp
Here is the implementation of the FC pass-through support for zfcp. The first patch is a fix required on top of the current linux-2.6 kernel and the second the actual implementation of the pass-through support. This requires the FC pass-through patch from James Smart.
As soon as the common FC pass-through supports gets integrated, i would like to add support for zfcp as well.
--
Christof Schmitt
PATCH 1/2 zfcp: Set WKA-port to offline on adapter deactivation
From: Swen Schillig <[email protected]>
The nameserver port might be in state online when the adapter is offlined. On adapter reactivation the nameserver port is not re-opened due to the PORT_ONLINE status. This results in an unsuccessful recovery. In forcing the nameserver port status to offline on all adapter offline events this issue is prevented.
---
drivers/s390/scsi/zfcp_aux.c | 3 ++- drivers/s390/scsi/zfcp_ccw.c | 1 - drivers/s390/scsi/zfcp_erp.c | 1 + drivers/s390/scsi/zfcp_ext.h | 1 + drivers/s390/scsi/zfcp_fc.c | 16 ++++++++++------ 5 files changed, 14 insertions(+), 8 deletions(-)
drivers/s390/scsi/zfcp_aux.c +2 -1
@@ -525,6 +525,8 @@ int zfcp_adapter_enqueue(struct ccw_deviatomic_clear_mask (ZFCP_STATUS_COMMON_REMOVE , &adapter->status); +zfcp_fc_nameserver_init (adapter); +if (!zfcp_adapter_scsi_register (adapter))return 0 ;
@@ -553,7 +555,6 @@ void zfcp_adapter_dequeue(struct zfcp_adcancel_work_sync (&adapter->scan_work);cancel_work_sync (&adapter->stat_work); -cancel_delayed_work_sync (&adapter->nsp.work);zfcp_adapter_scsi_unregister (adapter);sysfs_remove_group (&adapter->ccw_device->dev.kobj, &zfcp_sysfs_adapter_attrs);
drivers/s390/scsi/zfcp_ccw.c +0 -1
@@ -108,7 +108,6 @@ static int zfcp_ccw_set_online(struct cc/* initialize request counter */ BUG_ON (!zfcp_reqlist_isempty (adapter)); adapter->req_no =0 ; -zfcp_fc_nameserver_init (adapter);zfcp_erp_modify_adapter_status (adapter,"ccsonl1" ,NULL ,ZFCP_STATUS_COMMON_RUNNING ,ZFCP_SET );
drivers/s390/scsi/zfcp_erp.c +1 -0
@@ -719,6 +719,7 @@ static void zfcp_erp_adapter_strategy_clzfcp_qdio_close (adapter);zfcp_fsf_req_dismiss_all (adapter); adapter->fsf_req_seq_no =0 ; +zfcp_fc_wka_port_force_offline (&adapter->nsp);/* all ports and units are closed */ zfcp_erp_modify_adapter_status (adapter,"erascl1" ,NULL ,ZFCP_STATUS_COMMON_OPEN ,ZFCP_CLEAR );
drivers/s390/scsi/zfcp_ext.h +1 -0
@@ -106,6 +106,7 @@ extern void zfcp_fc_plogi_evaluate(strucextern void zfcp_test_link (struct zfcp_port *);extern void zfcp_fc_link_test_work (struct work_struct *);extern void zfcp_fc_nameserver_init (struct zfcp_adapter *); +extern void zfcp_fc_wka_port_force_offline (struct zfcp_wka_port *);/* zfcp_fsf.c */ extern int zfcp_fsf_open_port (struct zfcp_erp_action *);
drivers/s390/scsi/zfcp_fc.c +10 -6
@@ -98,12 +98,8 @@ static void zfcp_wka_port_offline(structstruct zfcp_wka_port *wka_port = container_of(dw, struct zfcp_wka_port, work); -/* Don't wait forvever. If the wka_port is too busy take it offline -through a new call later */ -if (!wait_event_timeout (wka_port->completion_wq, -atomic_read (&wka_port->refcount) ==0 , -HZ >>1 )) -return ; +wait_event (wka_port->completion_wq, +atomic_read (&wka_port->refcount) ==0 );mutex_lock (&wka_port->mutex); if ((atomic_read(&wka_port->refcount) != 0) ||
@@ -142,6 +138,14 @@ void zfcp_fc_nameserver_init(struct zfcpINIT_DELAYED_WORK (&wka_port->work, zfcp_wka_port_offline); } +void zfcp_fc_wka_port_force_offline (struct zfcp_wka_port *wka) +{ +cancel_delayed_work_sync (&wka->work); +mutex_lock (&wka->mutex); + wka->status =ZFCP_WKA_PORT_OFFLINE ; +mutex_unlock (&wka->mutex); +} +static void _zfcp_fc_incoming_rscn (struct zfcp_fsf_req *fsf_req,u32 range,struct fcp_rscn_element *elem) {
PATCH 2/2 zfcp: Add FC pass-through support
In reply to Christof SchmittFrom: Sven Schuetz <[email protected]>
Provide the ability to do fibre channel requests from the userspace to our zfcp driver. Patch builds upon extension to the fibre channel tranport class by James Smart and Seokmann Ju. See here
http://marc.info/?l=linux-scsi&m=123808882309133&w=2
--- drivers/s390/scsi/zfcp_aux.c | 10 +- drivers/s390/scsi/zfcp_def.h | 18 ++-- drivers/s390/scsi/zfcp_erp.c | 2 drivers/s390/scsi/zfcp_ext.h | 6 + drivers/s390/scsi/zfcp_fc.c | 188 +++++++++++++++++++++++++++++++++++++++--- drivers/s390/scsi/zfcp_scsi.c | 15 +++ 6 files changed, 219 insertions(+), 20 deletions(-)
drivers/s390/scsi/zfcp_aux.c +8 -2
@@ -471,6 +471,12 @@ int zfcp_adapter_enqueue(struct ccw_deviif (!adapter)return -ENOMEM ; + adapter->gs =kzalloc (sizeof (struct zfcp_wka_ports ),GFP_KERNEL ); +if (!adapter->gs) { +kfree (adapter); +return -ENOMEM ; + } + ccw_device->handler =NULL ; adapter->ccw_device = ccw_device;atomic_set (&adapter->refcount,0 );
@@ -524,8 +530,7 @@ int zfcp_adapter_enqueue(struct ccw_devi goto sysfs_failed;atomic_clear_mask (ZFCP_STATUS_COMMON_REMOVE , &adapter->status); - -zfcp_fc_nameserver_init (adapter); +zfcp_fc_wka_ports_init (adapter);if (!zfcp_adapter_scsi_register (adapter))return 0 ;
@@ -572,6 +577,7 @@ void zfcp_adapter_dequeue(struct zfcp_adkfree (adapter->req_list);kfree (adapter->fc_stats);kfree (adapter->stats_reset_data); +kfree (adapter->gs);kfree (adapter); }
drivers/s390/scsi/zfcp_def.h +12 -6
@@ -22,6 +22,8 @@#include <linux/syscalls.h> #include <linux/scatterlist.h> #include <linux/ioctl.h> +#include <scsi/fc/fc_fs.h> +#include <scsi/fc/fc_gs.h> #include <scsi/scsi.h> #include <scsi/scsi_tcq.h> #include <scsi/scsi_cmnd.h>
@@ -29,6 +31,7 @@#include <scsi/scsi_host.h> #include <scsi/scsi_transport.h> #include <scsi/scsi_transport_fc.h> +#include <scsi/scsi_bsg_fc.h> #include <asm/ccwdev.h> #include <asm/qdio.h> #include <asm/debug.h>
@@ -235,11 +238,6 @@ struct zfcp_ls_adisc {/* FC-PH/FC-GS well-known address identifiers for generic services */ #define ZFCP_DID_WKA 0xFFFFF0 -#define ZFCP_DID_MANAGEMENT_SERVICE 0xFFFFFA -#define ZFCP_DID_TIME_SERVICE 0xFFFFFB -#define ZFCP_DID_DIRECTORY_SERVICE 0xFFFFFC -#define ZFCP_DID_ALIAS_SERVICE 0xFFFFF8 -#define ZFCP_DID_KEY_DISTRIBUTION_SERVICE 0xFFFFF7/* remote port status */ #define ZFCP_STATUS_PORT_PHYS_OPEN 0x00000001
@@ -384,6 +382,14 @@ struct zfcp_wka_port {struct delayed_work work; }; +struct zfcp_wka_ports { +struct zfcp_wka_port ms;/* management service */ +struct zfcp_wka_port ts;/* time service */ +struct zfcp_wka_port ds;/* directory service */ +struct zfcp_wka_port as;/* alias service */ +struct zfcp_wka_port ks;/* key distribution service */ +}; +struct zfcp_qdio_queue {struct qdio_buffer *sbal[QDIO_MAX_BUFFERS_PER_Q ];u8 first;/* index of next free bfr in queue */
@@ -469,7 +475,7 @@ struct zfcp_adapter {actions */ u32 erp_low_mem_count;/* nr of erp actions waiting for memory */ -struct zfcp_wka_port nsp;/* adapter's nameserver */ +struct zfcp_wka_ports *gs;/* generic services */ debug_info_t *rec_dbf;debug_info_t *hba_dbf;debug_info_t *san_dbf;/* debug feature areas */
drivers/s390/scsi/zfcp_ext.h +5 -1
@@ -105,8 +105,12 @@ extern int zfcp_fc_ns_gid_pn(struct zfcpextern void zfcp_fc_plogi_evaluate (struct zfcp_port *,struct fsf_plogi *);extern void zfcp_test_link (struct zfcp_port *);extern void zfcp_fc_link_test_work (struct work_struct *); -extern void zfcp_fc_nameserver_init (struct zfcp_adapter *);extern void zfcp_fc_wka_port_force_offline (struct zfcp_wka_port *); +extern void zfcp_fc_wka_ports_init (struct zfcp_adapter *); +extern int zfcp_fc_execute_els_fc_job (struct fc_bsg_job *); +extern int zfcp_fc_execute_ct_fc_job (struct fc_bsg_job *); +extern void zfcp_fc_wka_port_force_offline (struct zfcp_wka_port *); +/* zfcp_fsf.c */ extern int zfcp_fsf_open_port (struct zfcp_erp_action *);
drivers/s390/scsi/zfcp_fc.c +178 -10
242 lines not on this page · raw message
drivers/s390/scsi/zfcp_scsi.c +15 -0
@@ -583,6 +583,20 @@ void zfcp_scsi_rport_work(struct work_st } +static int zfcp_execute_fc_job (struct fc_bsg_job *job) +{ +switch (job->request->msgcode) { +case FC_BSG_RPT_ELS : +case FC_BSG_HST_ELS_NOLOGIN : +return zfcp_fc_execute_els_fc_job (job); +case FC_BSG_RPT_CT : +case FC_BSG_HST_CT : +return zfcp_fc_execute_ct_fc_job (job); +default : +return -EINVAL ; + } +} +struct fc_function_template zfcp_transport_functions = { .show_starget_port_id =1 , .show_starget_port_name =1 ,
@@ -604,6 +618,7 @@ struct fc_function_template zfcp_transpo .dev_loss_tmo_callbk = zfcp_scsi_dev_loss_tmo_callbk, .terminate_rport_io = zfcp_scsi_terminate_rport_io, .show_host_port_state = 1, + .bsg_request = zfcp_execute_fc_job,/* no functions registered for following dynamic attributes but directly set by LLDD */ .show_host_port_type = 1,
drivers/s390/scsi/zfcp_erp.c +1 -1
@@ -719,7 +719,7 @@ static void zfcp_erp_adapter_strategy_clzfcp_qdio_close (adapter);zfcp_fsf_req_dismiss_all (adapter); adapter->fsf_req_seq_no =0 ; -zfcp_fc_wka_port_force_offline (&adapter->nsp); +zfcp_fc_wka_port_force_offline (&adapter->gs->ds);/* all ports and units are closed */ zfcp_erp_modify_adapter_status (adapter,"erascl1" ,NULL ,ZFCP_STATUS_COMMON_OPEN ,ZFCP_CLEAR );
Re: [patch 2/2] zfcp: Add FC pass-through support
Christof Schmitt wrote:
--- a/drivers/s390/scsi/zfcp_fc.c 2009-04-06 17:23:25.000000000 +0200
+++ b/drivers/s390/scsi/zfcp_fc.c 2009-04-06 17:24:30.000000000 +0200
...
Quoted 4 lines
drivers/s390/scsi/zfcp_fc.c +4
-0+static void zfcp_fc_generic_els_handler (unsigned long data) +{ +struct zfcp_els_fc_job *els_fc_job = (struct zfcp_els_fc_job *) data; +struct fc_bsg_job *job = els_fc_job->job;
drivers/s390/scsi/zfcp_fc.c void _zfcp_scan_ports_later(struct work_ · line 707
Quoted 10 lines
drivers/s390/scsi/zfcp_fc.c +10
-0+struct fc_bsg_reply *reply = job->reply; + +if (els_fc_job->els.status) { +/* request rejected or timed out */ + reply->reply_data.ctels_reply.status =FC_CTELS_STATUS_REJECT ; + goto out; + } + + reply->reply_data.ctels_reply.status =FC_CTELS_STATUS_OK ; + reply->reply_payload_rcv_len =blk_rq_bytes (job->req->next_rq);
My intent was to not have the LLDD reference (or even know about) the request structures and that bsg exists underneath.
Thus, for the last line above, it should be:
reply->reply_payload_rcv_len = job->reply_payload->data_len;
Although, I'm a little surprised that your els interface doesn't supply the
received data length to you, rather than the global assumption that you sized the reply buffer for exactly what you always get.
Quoted 4 lines
drivers/s390/scsi/zfcp_fc.c +4
-0+struct zfcp_ct_fc_job { +struct zfcp_send_ct ct; +struct fc_bsg_job *job; +};
drivers/s390/scsi/zfcp_fc.c void _zfcp_scan_ports_later(struct work_ · line 776
Quoted 10 lines
drivers/s390/scsi/zfcp_fc.c +10
-0+ +static void zfcp_fc_generic_ct_handler (unsigned long data) +{ +struct zfcp_ct_fc_job *ct_fc_job = (struct zfcp_ct_fc_job *) data; +struct fc_bsg_job *job = ct_fc_job->job; + + job->reply->reply_data.ctels_reply.status = ct_fc_job->ct.status ? +FC_CTELS_STATUS_REJECT :FC_CTELS_STATUS_OK ; + job->state_flags =FC_RQST_STATE_DONE ; + job->reply->reply_payload_rcv_len =blk_rq_bytes (job->req->next_rq);
same comment as above.
drivers/s390/scsi/zfcp_fc.c void _zfcp_scan_ports_later(struct work_ · line 782
Quoted 6 lines
drivers/s390/scsi/zfcp_fc.c +6
-0+ job->job_done (job); + +zfcp_wka_port_put (ct_fc_job->ct.wka_port); + +kfree (ct_fc_job); +}
Are you going to add support for the ELS/CT request timing out (e.g. for bsg_timeout callback) ?
Everything else looks good, and looks like it wasn't much effort to support. Great.
-- james s
Re: [patch 2/2] zfcp: Add FC pass-through support
Quoted 22 lines · James Smart
Christof Schmitt wrote:
drivers/s390/scsi/zfcp_fc.c 2009-04-06 17:24:30.000000000 +0200 renamed from drivers/s390/scsi/zfcp_fc.c 2009-04-06 17:23:25.000000000 +0200 +0
-0Quoted 4 lines
drivers/s390/scsi/zfcp_fc.c +4
-0+static void zfcp_fc_generic_els_handler (unsigned long data) +{ +struct zfcp_els_fc_job *els_fc_job = (struct zfcp_els_fc_job *) data; +struct fc_bsg_job *job = els_fc_job->job;drivers/s390/scsi/zfcp_fc.c void _zfcp_scan_ports_later(struct work_ · line 707
Quoted 10 lines
drivers/s390/scsi/zfcp_fc.c +10
-0+struct fc_bsg_reply *reply = job->reply; + +if (els_fc_job->els.status) { +/* request rejected or timed out */ + reply->reply_data.ctels_reply.status =FC_CTELS_STATUS_REJECT ; + goto out; + } + + reply->reply_data.ctels_reply.status =FC_CTELS_STATUS_OK ; + reply->reply_payload_rcv_len =blk_rq_bytes (job->req->next_rq);My intent was to not have the LLDD reference (or even know about) the request structures and that bsg exists underneath.
Quoted 6 lines
Thus, for the last line above, it should be:
reply->reply_payload_rcv_len = job->reply_payload->data_len;Although, I'm a little surprised that your els interface doesn't supply the received data length to you, rather than the global assumption that you sized the reply buffer for exactly what you always get.
I guess this is one thing we have to investigate. Either use the data_lan or get the data from the hardware.
Quoted 17 lines
Quoted 4 lines
drivers/s390/scsi/zfcp_fc.c +4
-0+struct zfcp_ct_fc_job { +struct zfcp_send_ct ct; +struct fc_bsg_job *job; +};drivers/s390/scsi/zfcp_fc.c void _zfcp_scan_ports_later(struct work_ · line 776
Quoted 10 lines
drivers/s390/scsi/zfcp_fc.c +10
-0+ +static void zfcp_fc_generic_ct_handler (unsigned long data) +{ +struct zfcp_ct_fc_job *ct_fc_job = (struct zfcp_ct_fc_job *) data; +struct fc_bsg_job *job = ct_fc_job->job; + + job->reply->reply_data.ctels_reply.status = ct_fc_job->ct.status ? +FC_CTELS_STATUS_REJECT :FC_CTELS_STATUS_OK ; + job->state_flags =FC_RQST_STATE_DONE ; + job->reply->reply_payload_rcv_len =blk_rq_bytes (job->req->next_rq);same comment as above.
Quoted 9 lines
drivers/s390/scsi/zfcp_fc.c void _zfcp_scan_ports_later(struct work_ · line 782
Quoted 6 lines
drivers/s390/scsi/zfcp_fc.c +6
-0+ job->job_done (job); + +zfcp_wka_port_put (ct_fc_job->ct.wka_port); + +kfree (ct_fc_job); +}Are you going to add support for the ELS/CT request timing out (e.g. for
bsg_timeoutcallback) ?
We don't have an interface to our hardware to abort ELS or CT requests. I suggested to remove the bsg_timeout callback, since there is not much zfcp can do here. Any pending request will timeout in the SAN or in the HBA if there is not response.
Quoted 2 lines
Everything else looks good, and looks like it wasn't much effort to support. Great.
Yes, the result looks good.
With 2.6.30-rc1 being out, the next merge window will be for 2.6.31. Are you going to push the FC passthrough support for 2.6.31?
--
Christof Schmitt
Re: [patch 2/2] zfcp: Add FC pass-through support
In reply to Christof SchmittQuoted 5 lines · On Mon, 06 Apr 2009 18:31:47 +0200 Christof Schmitt…
drivers/s390/scsi/zfcp_fc.c +5
-0+ els_fc_job->els.adapter = adapter; +if (rport) { +read_lock_irq (&zfcp_data.config_lock); + port = rport->dd_data; +if (port)
drivers/s390/scsi/zfcp_fc.c void _zfcp_scan_ports_later(struct work_ · line 748
Quoted 10 lines
drivers/s390/scsi/zfcp_fc.c +10
-0+zfcp_port_get (port); +read_unlock_irq (&zfcp_data.config_lock); +if (!port) { +kfree (els_fc_job); +return -EINVAL ; + } + els_fc_job->els.port = port; + els_fc_job->els.d_id = port->d_id; +zfcp_port_put (port); + }else {
This piece looks a bit strange. Why is the reference count of the port increased and afterwards decreased again? Still the pointer to the port gets added to els_fc_job->els.port and therefore the structure will be accessed later.
So either the reference count is decreased too early and this is a bug or it's not needed at all.
Re: [patch 2/2] zfcp: Add FC pass-through support
Quoted 23 lines · Heiko Carstens
Quoted 5 lines · On Mon, 06 Apr 2009 18:31:47 +0200 Christof Schmitt…
drivers/s390/scsi/zfcp_fc.c +5
-0+ els_fc_job->els.adapter = adapter; +if (rport) { +read_lock_irq (&zfcp_data.config_lock); + port = rport->dd_data; +if (port)drivers/s390/scsi/zfcp_fc.c void _zfcp_scan_ports_later(struct work_ · line 748
Quoted 10 lines
drivers/s390/scsi/zfcp_fc.c +10
-0+zfcp_port_get (port); +read_unlock_irq (&zfcp_data.config_lock); +if (!port) { +kfree (els_fc_job); +return -EINVAL ; + } + els_fc_job->els.port = port; + els_fc_job->els.d_id = port->d_id; +zfcp_port_put (port); + }else {This piece looks a bit strange. Why is the reference count of the port increased and afterwards decreased again? Still the pointer to the port gets added to
els_fc_job->els.portand therefore the structure will be accessed later.
Quoted 2 lines
So either the reference count is decreased too early and this is a bug or it's not needed at all.
Only the d_id is needed from the port, after this we don't access the port anymore. The assignment of the pointer to els.port is not required. We might do without the reference count and try to get the d_id while holding the config_lock.
Christof