On Mon, 2012-05-14 at 10:21 +0200, Bernhard Kohl wrote:
> Am 14.05.2012 05:34, schrieb ext Nicholas A. Bellinger:
> > On Sun, 2012-05-13 at 23:39 +0200, Bernhard Kohl wrote:
> >> The reservation must not be released if it is hold by a different ISID.
> >>
> >> Signed-off-by: Bernhard Kohl<bernhard.kohl@xxxxxxx>
> >> ---
> >> drivers/target/target_core_pr.c | 3 +++
> >> 1 files changed, 3 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/drivers/target/target_core_pr.c b/drivers/target/target_core_pr.c
> >> index eb48b15..5fd4dd3 100644
> >> --- a/drivers/target/target_core_pr.c
> >> +++ b/drivers/target/target_core_pr.c
> >> @@ -214,6 +214,9 @@ int target_scsi2_reservation_release(struct se_cmd *cmd)
> >> if (dev->dev_reserved_node_acl != sess->se_node_acl)
> >> goto out_unlock;
> >>
> >> + if (dev->dev_res_bin_isid != sess->sess_bin_isid)
> >> + goto out_unlock;
> >> +
> >> dev->dev_reserved_node_acl = NULL;
> >> dev->dev_flags&= ~DF_SPC2_RESERVATIONS;
> >> if (dev->dev_flags& DF_SPC2_RESERVATIONS_WITH_ISID) {
> > Hi Bernhard,
> >
> > I'm not sure if the iSCSI ISID check here really makes any difference
> > with legacy SPC-2 reservations, because ISIDs from different sessions to
> > the same iSCSI target endpoint are still going to be using the same
> > sess->se_node_acl pointer for different ISIDs to same InitiatorName..
> >
> > Do you have a use-case where this patch is really required..?
> >
> > --nab
> >
> Hi Nicholas,
>
> yes, I have an use case.
> We have an old OS which which does multi-initiator on SCSI disks.
> There are always 2 instances which access the same disk and coordinate
> this using SPC-2 RESERVE/RELEASE.
>
Hi Bernhard,
Thanks for the clarification on your client setup here..
I've applied this patch to lio-core with a few extra details on the
special iSCSI client case required to hit this bug..
> For testing I run these boxes in qemu-kvm on the same host. I configure
> the same backstores/fileio to one tpg via two different portals. Then
> I get e.g. /dev/sg8 and /dev/sg9 which are attached to the different
> VMs. Using /dev/sg* instead of /dev/sd* the guest's SCSI commands go
> through to the devices.
>
>
> For simple verification of the reservation the following should work.
>
> [bernd@lionel ~]$ # SCSI Reserve
> [bernd@lionel ~]$ sg_raw /dev/sg8 16 00 00 00 00 00
> SCSI Status: Good
>
> Sense Information:
> sense buffer empty
>
> [bernd@lionel ~]$ # SCSI Reserve
> [bernd@lionel ~]$ sg_raw /dev/sg9 16 00 00 00 00 00
> SCSI Status: Reservation Conflict
>
> Sense Information:
> sense buffer empty
>
> [bernd@lionel ~]$ # SCSI Release
> [bernd@lionel ~]$ sg_raw /dev/sg9 17 00 00 00 00 00
> SCSI Status: Good
>
> Sense Information:
> sense buffer empty
>
> [bernd@lionel ~]$ # SCSI Reserve
> [bernd@lionel ~]$ sg_raw /dev/sg9 16 00 00 00 00 00
> SCSI Status: Reservation Conflict
>
> Sense Information:
> sense buffer empty
>
<nod>
The simple sg_raw RESERVE/RELEASE test case here needs to be added to
scsi-testsuite.git (hch CC'ed), but AFAIK open-iscsi does not support
the "same InitiatorName + different ISID to a single TargetName
+TargetPortalGroupTag endpoint" configuration you've mentioned above..
Out of curiosity, what initiator / kernel are you using here..?
>
> Without my patch the second reservation conflict does not occur, which
> is definitely wrong. Doing the same with external iSCSI devices, e.g.
> EMC or HP (DotHill based SW), works well as expected.
>
I'm dropping this into target-pending/3.4-urgent shortly, and queue for
v3.4-final w/ CC to stable.
Thanks alot Bernhard !
--nab
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
