If an initiator sends a RELEASE6/10 but the initiator does not hold the reservation then nothing should happen. This is not an error.
This patch corrects TGTD so that it will return SUCCESS for this condition.
>From SPC-2 7.16.1 :
It is not an error for an application client to attempt to
release a reservation that is not currently valid, or is held
by another initiator. In this case, the device server shall
return GOOD status without altering any other reservation.
LIBISCSI contains a test for this, and TGTD now passes this test when this
patch is applied :
iscsi-test --test="*0420*" iscsi://127.0.0.1/iqn.ronnie.test/1
0420_reserve6_simple:
===================
Send RESERVE6 ... [OK]
Send RELEASE6 ... [OK]
Test that reservation works.
Send RESERVE6 from Initiator 1. ... [OK]
[OK]
Send RESERVE6 from Initiator 2. Expect conflict. ... [OK]
Send RELEASE6 from Initiator 2..Expect NO-OP. ... [OK]
Send TESTUNITREADY from Initiator 1 ... [OK]
Send TESTUNITREADY from Initiator 2. Expect conflict. ... [OK]
Test that release actually works
Send RELEASE6 from Initiator 1 ... [OK]
Send RESERVE6 Initiator 2 ... [OK]
Send RELEASE6 Initiator 2 ... [OK]
TEST T0420_reserve6_simple [OK]
Signed-off-by: Ronnie Sahlberg <ronniesahlberg@xxxxxxxxx>
---
usr/target.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/usr/target.c b/usr/target.c
index a8bcdbb..7b9ae12 100644
--- a/usr/target.c
+++ b/usr/target.c
@@ -887,6 +887,9 @@ int device_release(int tid, uint64_t itn_id, uint64_t lun, int force)
return 0;
}
+ if (lu->reserve_id != itn_id)
+ return 0;
+
return -EBUSY;
}
--
1.7.3.1
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
