Re: [patch 2/5] zfcp: Handle WWPN mismatch in PLOGI payload

[Christof Schmitt <christof.schmitt@de.ibm.com>]

On Tue, Oct 13, 2009 at 09:51:39AM -0700, Joe Eykholt wrote:
>> For ports, zfcp gets the DID from the FC nameserver and tries to open
>> the port. If the open succeeds, zfcp compares the WWPN from the
>> nameserver with the WWPN in the PLOGI payload. In case of a mismatch,
>> zfcp assumes that the DID of the port just changed and we opened the
>> wrong port. This means that zfcp has to forget the DID, lookup the DID
>> again and retry.
>
> Does this happen very often?  Would you get an RSCN if a target's WWPN changed?
> Just wondering how this happens and whether libfc needs similar defenses.
> Is it due to a broken target?

zfcp first gets all DIDs from the nameserver and then triggers to
login to all ports. A change could happen at any time. With the RSCNs
being asynchronous to the login, we have to check if the port is
really the one we wanted to login to. James S. pointed out some more
details.

In this particular case i am seeing in out test environment, the
storage target always returns a wrong WWPN. I would recommend that any
check being done also considers targets that return wrong data to
avoid endless loops and such.

> See below for a minor typo.

[...]

>> diff -urpN linux-2.6/drivers/s390/scsi/zfcp_fc.c linux-2.6-patched/drivers/s390/scsi/zfcp_fc.c
>> --- linux-2.6/drivers/s390/scsi/zfcp_fc.c	2009-10-07 10:16:33.000000000 +0200
>> +++ linux-2.6-patched/drivers/s390/scsi/zfcp_fc.c	2009-10-07 10:17:01.000000000 +0200
>> @@ -361,6 +361,17 @@ out:
>>  }
>>   /**
>> + * zfcp_fc_trigger_did_ookup - trigger the d_id lookup using a GPN_FT request
>
> s/ook/look/
>
> I just happened to notice that.  I didn't review the rest.

Thanks for catching this. And looking at the line, it is supposed to
read GID_PN and not GPN_FT.

I will resend the patch with the updated comment.

--
Christof