qla2xxx: Fix kernel panic on selective retransmission request
authorDr. Greg Wettstein <greg@enjellic.com>
Mon, 24 Feb 2014 19:59:53 +0000 (13:59 -0600)
committerNicholas Bellinger <nab@linux-iscsi.org>
Mon, 24 Feb 2014 21:34:18 +0000 (13:34 -0800)
commit6f58c780e5a5b43a6d2121e0d43cdcba1d3cc5fc
treebd827295874ecd2dd35f041f328a3338e2f29d08
parentfc272ec7a2dfe002b823c78f8ef0eb88042e2762
qla2xxx: Fix kernel panic on selective retransmission request

A selective retransmission request (SRR) is a fibre-channel
protocol control request which provides support for requesting
retransmission of a data sequence in response to an issue such as
frame loss or corruption.  These events are experienced
infrequently in fibre-channel based networks which makes
it difficult to test and assess codepaths which handle these
events.

We were fortunate enough, for some definition of fortunate, to
have a metro-area single-mode SAN link which, at 10 GBPS
sustained load levels, would consistently generate SRR's in
a SCST based target implementation using our SCST/in-kernel
Qlogic target interface driver.  In response to an SRR the
in-kernel Qlogic target driver immediately panics resulting
in a catastrophic storage failure for serviced initiators.

The culprit was a debug statement in the qla_target.c file which
does not verify that a pointer to the SCSI CDB is not null.
The unchecked pointer dereference results in the kernel panic
and resultant system failure.

The other two references to the SCSI CDB by the SRR handling code
use a ternary operator to verify a non-null pointer is being
acted on.  This patch simply adds a similar test to the implicated
debug statement.

This patch is a candidate for any stable kernel being maintained
since it addresses a potentially catastrophic event with
minimal downside.

Signed-off-by: Dr. Greg Wettstein <greg@enjellic.com>
Cc: <stable@vger.kernel.org> #3.5+
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
drivers/scsi/qla2xxx/qla_target.c