From 480584818a4bb3655d8d0d875ed60b427fc61cc5 Mon Sep 17 00:00:00 2001 From: Kiran Patil Date: Mon, 20 Jun 2011 16:58:59 -0700 Subject: [SCSI] libfc: Enhancement to RPORT state machine applicable only for VN2VN mode Problem: Existing RPORT state machine continues witg FLOGI/PLOGI process only after it receices beacon from other end. Once claiming stage is over (either clain notify or clain repose), beacon is sent and state machine enters into operational mode where it initiates the rlogin process (FLOGI/PLOGI) to the peer but before this rlogin is initiated, exitsing implementation checks if it received beacon from other end, it beacon is not received yet, rlogin process is not initiated. Other end initiates FLOGI but peer end keeps on rejecting FLOGI, hence after 3 retries other end deletes associated rport, then sends a beacon. Once the beacon is received, peer end now initiates rlogin to the peer end but since associated rport is deleted FLOGI is neither accepted nor the reject response send out because rport is deleted. Hence unable to proceed withg FLOGI/PLOGI process and fails to establish VN2VN connection. Fix: VN2VN spec is not standard yet but based on exitsing collateral on T11, it appears that, both end shall send beacon and enter into 'operational mode' without explictly waiting for beacon from other end. Fix is to allow the RPORT login process as long as respective RPORT is created (as part of claim notification / claim response) even though state of RPORT is INIT. Means don't wait for beacon from peer end, if peer end initiates FLOGI (means peer end exist and responding). Notes: This patch is preparing the FCoE stack for target wrt offload. This is generic patch and harmless even if applied on storage initiator because 'else if' condition of function 'fcoe_oem_found' shall evaluate to TRUE only for targets. Dependencies: None Signed-off-by: Kiran Patil Signed-off-by: Robert Love Signed-off-by: James Bottomley --- drivers/scsi/libfc/fc_rport.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) (limited to 'drivers/scsi/libfc') diff --git a/drivers/scsi/libfc/fc_rport.c b/drivers/scsi/libfc/fc_rport.c index 49e1ccca09d5..3b6693774066 100644 --- a/drivers/scsi/libfc/fc_rport.c +++ b/drivers/scsi/libfc/fc_rport.c @@ -801,6 +801,20 @@ static void fc_rport_recv_flogi_req(struct fc_lport *lport, switch (rdata->rp_state) { case RPORT_ST_INIT: + /* + * If received the FLOGI request on RPORT which is INIT state + * (means not transition to FLOGI either fc_rport timeout + * function didn;t trigger or this end hasn;t received + * beacon yet from other end. In that case only, allow RPORT + * state machine to continue, otherwise fall through which + * causes the code to send reject response. + * NOTE; Not checking for FIP->state such as VNMP_UP or + * VNMP_CLAIM because if FIP state is not one of those, + * RPORT wouldn;t have created and 'rport_lookup' would have + * failed anyway in that case. + */ + if (lport->point_to_multipoint) + break; case RPORT_ST_DELETE: mutex_unlock(&rdata->rp_mutex); rjt_data.reason = ELS_RJT_FIP; -- cgit v1.2.3 From e3e65c69c3cfe8e407797c78fd11808aee1a8a81 Mon Sep 17 00:00:00 2001 From: Kiran Patil Date: Mon, 20 Jun 2011 16:59:30 -0700 Subject: [SCSI] libfc:Fix for exchange/seq loopup failure when FCoE stack is used as target and connected to windows initaitor Problem: Linux based SW target (TCM) connected to windows initiator was unable to satisfy write request of size > 2K. Fix: Existing linux implememtation of FCoE stack is expecting sequence number to match w.r.t incoming framme. When DDP is used on target in response to write request from initiator, SW stack is notified only when last data frame arrives and only the pakcket header of last data frame is posted to NetRx queue of storage. When that last packet was processed in libfc:Exchange layer, implementation was expecting sequence number to match, but in this case sequence number which is embedded in FC Header is assigned by windows initaitor, hence due to sequence number mismatch post-processing which shall result into sending RSP is not done. Enhanced the code to utilize the sequence number of incoming last frame and process the packet so that, it will eventually complete the write request by sending write response (RSP) GOOD. Notes/Dependencies: This patch is validated using windows and linux initiator to make sure, it doesn't break anything. Signed-off-by: Kiran Patil Signed-off-by: Robert Love Signed-off-by: James Bottomley --- drivers/scsi/libfc/fc_exch.c | 26 ++++++++++++++++++++++++-- 1 file changed, 24 insertions(+), 2 deletions(-) (limited to 'drivers/scsi/libfc') diff --git a/drivers/scsi/libfc/fc_exch.c b/drivers/scsi/libfc/fc_exch.c index 3b8a6451ea28..f5a0665b6773 100644 --- a/drivers/scsi/libfc/fc_exch.c +++ b/drivers/scsi/libfc/fc_exch.c @@ -965,8 +965,30 @@ static enum fc_pf_rjt_reason fc_seq_lookup_recip(struct fc_lport *lport, sp = &ep->seq; if (sp->id != fh->fh_seq_id) { atomic_inc(&mp->stats.seq_not_found); - reject = FC_RJT_SEQ_ID; /* sequence/exch should exist */ - goto rel; + if (f_ctl & FC_FC_END_SEQ) { + /* + * Update sequence_id based on incoming last + * frame of sequence exchange. This is needed + * for FCoE target where DDP has been used + * on target where, stack is indicated only + * about last frame's (payload _header) header. + * Whereas "seq_id" which is part of + * frame_header is allocated by initiator + * which is totally different from "seq_id" + * allocated when XFER_RDY was sent by target. + * To avoid false -ve which results into not + * sending RSP, hence write request on other + * end never finishes. + */ + spin_lock_bh(&ep->ex_lock); + sp->ssb_stat |= SSB_ST_RESP; + sp->id = fh->fh_seq_id; + spin_unlock_bh(&ep->ex_lock); + } else { + /* sequence/exch should exist */ + reject = FC_RJT_SEQ_ID; + goto rel; + } } } WARN_ON(ep != fc_seq_exch(sp)); -- cgit v1.2.3 From 9b7d1613a9060b7c82ac7e8e7cbee8c2392925c2 Mon Sep 17 00:00:00 2001 From: Vasu Dev Date: Mon, 20 Jun 2011 16:59:46 -0700 Subject: [SCSI] libfc: post reset event on lport reset Post an FCH_EVT_LIPRESET event on lport reset as as lport reset occurs on FIP cleat virtual link, this could be due to change in fcoe vlan and this event will allow user app fcoemon to switch to new fcoe vlan. Signed-off-by: Vasu Dev Tested-by: Ross Brattain Signed-off-by: Robert Love Signed-off-by: James Bottomley --- drivers/scsi/libfc/fc_lport.c | 2 ++ 1 file changed, 2 insertions(+) (limited to 'drivers/scsi/libfc') diff --git a/drivers/scsi/libfc/fc_lport.c b/drivers/scsi/libfc/fc_lport.c index 389ab80aef0a..e008b1673507 100644 --- a/drivers/scsi/libfc/fc_lport.c +++ b/drivers/scsi/libfc/fc_lport.c @@ -1025,6 +1025,8 @@ static void fc_lport_enter_reset(struct fc_lport *lport) fc_vport_set_state(lport->vport, FC_VPORT_LINKDOWN); } fc_lport_state_enter(lport, LPORT_ST_RESET); + fc_host_post_event(lport->host, fc_get_event_number(), + FCH_EVT_LIPRESET, 0); fc_vports_linkchange(lport); fc_lport_reset_locked(lport); if (lport->link_up) -- cgit v1.2.3