On 3/18/2015 4:45 PM, Christophe Vu-Brugier wrote:
A check that rejects a CDB with FUA bit set if no write cache is
emulated was added by the following commit:
fde9f50 target: Add sanity checks for DPO/FUA bit usage
However, this additional check is wrong: if FUA is supported or
emulated, then CDBs with FUA bit set should be accepted.
Signed-off-by: Christophe Vu-Brugier <cvubrugier@xxxxxxxxxxx>
---
drivers/target/target_core_sbc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/target/target_core_sbc.c b/drivers/target/target_core_sbc.c
index 856e800..a4431b4 100644
--- a/drivers/target/target_core_sbc.c
+++ b/drivers/target/target_core_sbc.c
@@ -703,8 +703,7 @@ sbc_check_dpofua(struct se_device *dev, struct se_cmd *cmd, unsigned char *cdb)
}
}
if (cdb[1] & 0x8) {
- if (!dev->dev_attrib.emulate_fua_write ||
- !dev->dev_attrib.emulate_write_cache) {
+ if (!dev->dev_attrib.emulate_fua_write) {
pr_err("Got CDB: 0x%02x with FUA bit set, but device"
" does not advertise support for FUA write\n",
cdb[0]);
Why did the initiator thinks the device supports FUA if the
modsense response depends on both FUA and WCE?
static sense_reason_t spc_emulate_modesense(struct se_cmd *cmd)
{
....
if ((spc_check_dev_wce(dev)) &&
(dev->dev_attrib.emulate_fua_write > 0))
spc_modesense_dpofua(&buf[length], type);
....
}
I think maybe the device supports WCE but wasn't explicitly set with
emulate_write_cache. Perhaps the check should be
if (!dev->dev_attrib.emulate_fua_write || !spc_check_dev_wce(dev))
Thoughts?
Sagi.
--
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
