• Steffen Maier's avatar
    scsi: zfcp: fix capping of unsuccessful GPN_FT SAN response trace records · 975171b4
    Steffen Maier authored
    v4.9 commit aceeffbb ("zfcp: trace full payload of all SAN records
    (req,resp,iels)") fixed trace data loss of 2.6.38 commit 2c55b750
    ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.")
    necessary for problem determination, e.g. to see the
    currently active zone set during automatic port scan.
    
    While it already saves space by not dumping any empty residual entries
    of the large successful GPN_FT response (4 pages), there are seldom cases
    where the GPN_FT response is unsuccessful and likely does not have
    FC_NS_FID_LAST set in fp_flags so we did not cap the trace record.
    We typically see such case for an initiator WWPN, which is not in any zone.
    
    Cap unsuccessful responses to at least the actual basic CT_IU response
    plus whatever fits the SAN trace record built-in "payload" buffer
    just in case there's trailing information
    of which we would at least see the existence and its beginning.
    
    In order not to erroneously cap successful responses, we need to swap
    calling the trace function and setting the CT / ELS status to success (0).
    
    Example trace record pair formatted with zfcpdbf:
    
    Timestamp      : ...
    Area           : SAN
    Subarea        : 00
    Level          : 1
    Exception      : -
    CPU ID         : ..
    Caller         : 0x...
    Record ID      : 1
    Tag            : fssct_1
    Request ID     : 0x<request_id>
    Destination ID : 0x00fffffc
    SAN req short  : 01000000 fc020000 01720ffc 00000000
                     00000008
    SAN req length : 20
    |
    Timestamp      : ...
    Area           : SAN
    Subarea        : 00
    Level          : 1
    Exception      : -
    CPU ID         : ..
    Caller         : 0x...
    Record ID      : 2
    Tag            : fsscth2
    Request ID     : 0x<request_id>
    Destination ID : 0x00fffffc
    SAN resp short : 01000000 fc020000 80010000 00090700
                     00000000 00000000 00000000 00000000 [trailing info]
                     00000000 00000000 00000000 00000000 [trailing info]
    SAN resp length: 16384
    San resp info  : 01000000 fc020000 80010000 00090700
                     00000000 00000000 00000000 00000000 [trailing info]
                     00000000 00000000 00000000 00000000 [trailing info]
                     00000000 00000000 00000000 00000000 [trailing info]
                     00000000 00000000 00000000 00000000 [trailing info]
                     00000000 00000000 00000000 00000000 [trailing info]
                     00000000 00000000 00000000 00000000 [trailing info]
                     00000000 00000000 00000000 00000000 [trailing info]
                     00000000 00000000 00000000 00000000 [trailing info]
                     00000000 00000000 00000000 00000000 [trailing info]
                     00000000 00000000 00000000 00000000 [trailing info]
                     00000000 00000000 00000000 00000000 [trailing info]
                     00000000 00000000 00000000 00000000 [trailing info]
                     00000000 00000000 00000000 00000000 [trailing info]
                     00000000 00000000 00000000 00000000 [trailing info]
                     00000000 00000000 00000000 00000000 [trailing info]
    
    The fix saves all but one of the previously associated 64 PAYload trace
    record chunks of size 256 bytes each.
    Signed-off-by: default avatarSteffen Maier <maier@linux.vnet.ibm.com>
    Fixes: aceeffbb ("zfcp: trace full payload of all SAN records (req,resp,iels)")
    Fixes: 2c55b750 ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.")
    Cc: <stable@vger.kernel.org> #2.6.38+
    Reviewed-by: default avatarBenjamin Block <bblock@linux.vnet.ibm.com>
    Signed-off-by: default avatarBenjamin Block <bblock@linux.vnet.ibm.com>
    Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
    975171b4
zfcp_dbf.c 19.8 KB