zfcp: fix D_ID field with actual value on tracing SAN responses
authorSteffen Maier <maier@linux.vnet.ibm.com>
Wed, 10 Aug 2016 16:30:51 +0000 (18:30 +0200)
committerMartin K. Petersen <martin.petersen@oracle.com>
Fri, 12 Aug 2016 20:17:12 +0000 (16:17 -0400)
commit771bf03537ddfa4a4dde62ef9dfbc82e4f77ab20
tree89d79baee2205a72ed5c7d224f0cb6029d35c66a
parent7c964ffe586bc0c3d9febe9bf97a2e4b2866e5b7
zfcp: fix D_ID field with actual value on tracing SAN responses

With commit 2c55b750a884b86dea8b4cc5f15e1484cc47a25c
("[SCSI] zfcp: Redesign of the debug tracing for SAN records.")
we lost the N_Port-ID where an ELS response comes from.
With commit 7c7dc196814b9e1d5cc254dc579a5fa78ae524f7
("[SCSI] zfcp: Simplify handling of ct and els requests")
we lost the N_Port-ID where a CT response comes from.
It's especially useful if the request SAN trace record
with D_ID was already lost due to trace buffer wrap.

GS uses an open WKA port handle and ELS just a D_ID, and
only for ELS we could get D_ID from QTCB bottom via zfcp_fsf_req.
To cover both cases, add a new field to zfcp_fsf_ct_els
and fill it in on request to use in SAN response trace.
Strictly speaking the D_ID on SAN response is the FC frame's S_ID.
We don't need a field for the other end which is always us.

Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Fixes: 2c55b750a884 ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.")
Fixes: 7c7dc196814b ("[SCSI] zfcp: Simplify handling of ct and els requests")
Cc: <stable@vger.kernel.org> #2.6.38+
Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
drivers/s390/scsi/zfcp_dbf.c
drivers/s390/scsi/zfcp_fsf.c
drivers/s390/scsi/zfcp_fsf.h
This page took 0.024814 seconds and 5 git commands to generate.