From: Roland Dreier <roland@xxxxxxxxxxxxxxx>
> Shouldn't the code actually report the virtual lun zero instead of just
> accounting for it?
Yeah, I think there is an implicit memset to 0 somewhere that is
saving us, but the below is probably better.
- R.
-------- 8< --------
Subject: [PATCH] target: REPORT LUNS should return LUN 0 even for dynamic ACLs
From: Roland Dreier <roland@xxxxxxxxxxxxxxx>
If an initiator doesn't have any real LUNs assigned, we should report
LUN 0 and a LUN list length of 1. Some versions of Solaris at least
go beserk if we report a LUN list length of 0.
Signed-off-by: Roland Dreier <roland@xxxxxxxxxxxxxxx>
---
drivers/target/target_core_spc.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/target/target_core_spc.c b/drivers/target/target_core_spc.c
index b0744433315a..d9039c487768 100644
--- a/drivers/target/target_core_spc.c
+++ b/drivers/target/target_core_spc.c
@@ -1214,11 +1214,9 @@ sense_reason_t spc_emulate_report_luns(struct se_cmd *cmd)
* coming via a target_core_mod PASSTHROUGH op, and not through
* a $FABRIC_MOD. In that case, report LUN=0 only.
*/
- if (!sess) {
- int_to_scsilun(0, (struct scsi_lun *)&buf[offset]);
- lun_count = 1;
+ if (!sess)
goto done;
- }
+
nacl = sess->se_node_acl;
rcu_read_lock();
@@ -1241,6 +1239,14 @@ sense_reason_t spc_emulate_report_luns(struct se_cmd *cmd)
* See SPC3 r07, page 159.
*/
done:
+ /*
+ * If no LUNs are accessible, report virtual LUN 0.
+ */
+ if (lun_count == 0) {
+ int_to_scsilun(0, (struct scsi_lun *)&buf[offset]);
+ lun_count = 1;
+ }
+
lun_count *= 8;
buf[0] = ((lun_count >> 24) & 0xff);
buf[1] = ((lun_count >> 16) & 0xff);
--
2.1.4
--
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
