On Fri, 2015-07-24 at 12:11 -0700, Roland Dreier wrote:
> 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);
Applied to target-pending/master w/ extra CC for v3.1+.
Thanks Roland + HCH.
--
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
