In the case where there are multiple registrants and a single reservation
holder, the PR IN Service Action READ FULL STATUS was either returning
that nobody had a reservation, or that all registrants had a reservation,
depending on which initiator queried the target.
This patch fixes that bug by using the Session ID of each initiator when
making this check, instead of the Session ID of the current initiator.
Tested on SLES 11 SP 2, with 2 seperate open-iscsi initiators.
Signed-off-by: Lee Duncan
persist.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
============================================================
--- iscsitarget-1.4.20.3-svn.orig/kernel/persist.c 2012-03-12 14:13:26.000000000 -0700
+++ iscsitarget-1.4.20.3-svn.new/kernel/persist.c 2012-03-19 21:00:49.000000000 -0700
@@ -16,6 +16,13 @@ pr_is_reserved_by_session(const struct r
return (pr_is_reserved(res) && res->sid == sess->sid);
}
+static bool
+pr_is_reserved_by_sid(const struct reservation *res,
+ const u64 sid)
+{
+ return (pr_is_reserved(res) && res->sid == sid);
+}
+
bool
pr_initiator_has_registered(const struct reservation *res,
u64 sid)
@@ -132,8 +139,7 @@ pr_in_read_full_status(struct iscsi_cmnd
const struct pr_in_full_status_descriptor desc = {
.reservation_key = reg->reservation_key,
.all_tg_pt_r_holder =
- pr_is_reserved_by_session(reservation,
- cmnd->conn->session),
+ pr_is_reserved_by_sid(reservation, reg->sid),
.scope_type = PR_SCOPE_LU|reservation->persistent_type,
/* only rel_tgt_port_id 1 is supported */
.rel_tgt_port_id = cpu_to_be16(1),
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Iscsitarget-devel mailing list
Iscsitar...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel
I did not see an Ack. Can I assume this patch is accepted?
I have one more patch to submit, for extending persistent reservation
support (as discussed on this list earlier), and I'm not sure whether to
submit it against the current trunk (r467) or again trunk plus my last
patch. But if the last patch will soon be in trunk, that would answer my
question.
Preferences?
(Note: please correct my spelling of "separate" in my patch description!)
--
Lee Duncan
SUSE Labs
No problem! I was just unsure of the process. I did not mean to be pushy.
I'll submit the persistent reservation patch this evening or tomorrow.
Thanks!
On 03/21/2012 05:12 PM, Ross S. W. Walker wrote:
>
> Sorry,
>
> I haven't had time to verify, but keep them coming, it's informal and often we will fix issues during commit.
>
> I will try to get some time on the weekend to look them over unless Arne get's to it first.
>
> -Ross
> ______________________________________________________________________
> This e-mail, and any attachments thereto, is intended only for use by
> the addressee(s) named herein and may contain legally privileged
> and/or confidential information. If you are not the intended recipient
> of this e-mail, you are hereby notified that any dissemination,
> distribution or copying of this e-mail, and any attachments thereto,
> is strictly prohibited. If you have received this e-mail in error,
> please immediately notify the sender and permanently delete the
> original and any copy or printout thereof.
Applied, thanks a lot.
Arne