[ 39/41] iscsi-target: Fix reservation conflict -EBUSY response handling bug

[Greg KH]

3.2-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Nicholas Bellinger <nab@xxxxxxxxxxxxxxx>

commit 00fdc6bbef77844ce397a7de7acfaf25e8e2e4eb upstream.

This patch addresses a iscsi-target specific bug related to reservation conflict
handling in iscsit_handle_scsi_cmd() that has been causing reservation conflicts
to complete and not fail as expected due to incorrect errno checking.  The problem
occured with the change to return -EBUSY from transport_generic_cmd_sequencer() ->
transport_generic_allocate_tasks() failures, that broke iscsit_handle_scsi_cmd()
checking for -EINVAL in order to invoke a non GOOD status response.

This was manifesting itself as data corruption with legacy SPC-2 reservations,
but also effects iscsi-target LUNs with SPC-3 persistent reservations.

This bug was originally introduced in lio-core commit:

commit 03e98c9eb916f3f0868c1dc344dde2a60287ff72
Author: Nicholas Bellinger <nab@xxxxxxxxxxxxxxx>
Date:   Fri Nov 4 02:36:16 2011 -0700

    target: Address legacy PYX_TRANSPORT_* return code breakage

Reported-by: Martin Svec <martin.svec@xxxxxxxx>
Cc: Martin Svec <martin.svec@xxxxxxxx>
Cc: Christoph Hellwig <hch@xxxxxx>
Signed-off-by: Nicholas Bellinger <nab@xxxxxxxxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>

---
 drivers/target/iscsi/iscsi_target.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/target/iscsi/iscsi_target.c
+++ b/drivers/target/iscsi/iscsi_target.c
@@ -1029,7 +1029,7 @@ done:
 		return iscsit_add_reject_from_cmd(
 				ISCSI_REASON_BOOKMARK_NO_RESOURCES,
 				1, 1, buf, cmd);
-	} else if (transport_ret == -EINVAL) {
+	} else if (transport_ret < 0) {
 		/*
 		 * Unsupported SAM Opcode.  CHECK_CONDITION will be sent
 		 * in iscsit_execute_cmd() during the CmdSN OOO Execution


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/