Hi Nic,
in struct se_dev_attrib, there is a field emulate_caw.
If this field is set zero, does it mean that the corresponding struct se_device does not support the scsi cmd COMPARE_AND_WRITE?
Do fields like emulate_tpws, emulate_tpu, emulate_tas... imply "enable support for thin provision write same", "enable support for
thin provision unmap", "enable support for task aborted status"?
In function sbc_parse_cdb(), it rejects scsi cmd UNMAP if emulate_tpu is not set. So I think we should also reject COMPARE_AND_WRITE if emulate_caw is not set.
I propose a patch:
Signed-off-by: Jiang Yi <jiangyilism@xxxxxxxxx>
---
drivers/target/target_core_sbc.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/target/target_core_sbc.c b/drivers/target/target_core_sbc.c
index 4316f7b..bdea345 100644
--- a/drivers/target/target_core_sbc.c
+++ b/drivers/target/target_core_sbc.c
@@ -1005,6 +1005,12 @@ sbc_parse_cdb(struct se_cmd *cmd, struct sbc_ops *ops)
break;
}
case COMPARE_AND_WRITE:
+ if (!dev->dev_attrib.emulate_caw) {
+ pr_err("se_device %s/%s (vpd_unit_serial %s) reject COMPARE_AND_WRITE\n",
+ dev->se_hba->backend->ops->name, dev->dev_group.cg_item.ci_name,
+ dev->t10_wwn.unit_serial);
+ return TCM_UNSUPPORTED_SCSI_OPCODE;
+ }
sectors = cdb[13];
/*
* Currently enforce COMPARE_AND_WRITE for a single sector
--
2.5.0
Also I notice that when printing error/debug logs about a se_device, we currently do not provide much information to identify which se_device the log corresponds to. Such as
pr_err("Got UNMAP, but backend device has"
" emulate_tpu disabled\n");
and
pr_err("Got CDB: 0x%02x with FUA bit set, but device"
" does not advertise support for FUA write\n",
cdb[0]);
I think we can provide more information like se_hba name and t10_wwn.unit_serial like the patch I just proposed. hba type provides much information what the "characteristic" the se_device has and unit_serial is the identifier used by iscsi initiators(I use ESXi, unit_serial corresponds to the naa of the connected iscsi disk). Are all these information considered sensitive so is not recommended to be left in syslog? If you think printing more detailed se_device information in syslog is a good idea, I will send another patch to rewrite many places in target_core_mod.ko to do so.
by Jiang Yi
--
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
