If a Simple command is sent with an Unsupported SCSI Opcode (failure),
target_setup_cmd_from_cdb returns with TCM_UNSUPPORTED_SCSI_OPCODE
which then causes transport_generic_request_failure to decrement
simple_cmds, due to call to transport_complete_task_attr.
With this dev->simple_cmds or dev->dev_ordered_sync is now -1, not 0.
So when a subsequent command with an Ordered Task is sent, it causes
a hang, since dev->simple_cmds is at -1. Thus to prevent Unsupported
SCSI Opcode Failure from decrementing simple_cmds I added a check
to skip transport_complete_task_attr for sense_reaons that are
TCM_UNSUPPORTED_SCSI_OPCODE.
I dont know if this is a proper fix, but it worked for me, let me
know what you think Nick.
Signed-off-by: Bryant G. Ly <bryantly@xxxxxxxxxxxxxxxxxx>
---
drivers/target/target_core_transport.c | 22 +++++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/target/target_core_transport.c b/drivers/target/target_core_transport.c
index 6c089af..e38aef0 100644
--- a/drivers/target/target_core_transport.c
+++ b/drivers/target/target_core_transport.c
@@ -1684,7 +1684,8 @@ void transport_generic_request_failure(struct se_cmd *cmd,
/*
* For SAM Task Attribute emulation for failed struct se_cmd
*/
- transport_complete_task_attr(cmd);
+ if (sense_reason != TCM_UNSUPPORTED_SCSI_OPCODE)
+ transport_complete_task_attr(cmd);
/*
* Handle special case for COMPARE_AND_WRITE failure, where the
* callback is expected to drop the per device ->caw_sem.
@@ -3096,6 +3097,25 @@ target_check_wce(struct se_device *dev)
wce = true;
return wce;
+ spin_unlock_irqrestore(&cmd->t_state_lock, flags);
+
+ INIT_WORK(&cmd->work, target_tmr_work);
+ queue_work(cmd->se_dev->tmr_wq, &cmd->work);
+ return 0;
+}
+EXPORT_SYMBOL(transport_generic_handle_tmr);
+
+bool
+target_check_wce(struct se_device *dev)
+{
+ bool wce = false;
+
+ if (dev->transport->get_write_cache)
+ wce = dev->transport->get_write_cache(dev);
+ else if (dev->dev_attrib.emulate_write_cache > 0)
+ wce = true;
+
+ return wce;
}
bool
--
[ 3043.859545] Incremented dev->dev_cur_ordered_id: 25311 for SIMPLE,
simple_cmd:-4
[ 3043.859547] ibmvscsis: queue_data_in, se_cmd c0000000fba7bb18, length 0x20
[ 3043.859552] ibmvscsis: rdma: dir 2, bytes 0x20
[ 3043.859554] data:1f 00 10 08 02 5f ff ff 00 00 02 00 08 12 04 00 ....._...
[ 3043.859556] data:00 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00 ........
[ 3043.859564] ibmvscsis: release_cmd c0000000fba7bb18, flags 0
[ 3043.859566] ibmvscsis: send_messages cmd c0000000fba7bb08
[ 3043.859571] ibmvscsis: send_messages: tag 0xe882280b000000c0, rc 0
[ 3043.859632] ibmvscsis: got interrupt
[ 3043.859638] ibmvscsis: copy_crq: ioba 0x18014800, init_time 0x17760a12fb1
[ 3043.859640] ibmvscsis: srp_cmd tag: 13835058055469368512 (0xc00000000b2884c0)
[ 3043.859643] ibmvscsis: handle_crq, reenabling interrupts
[ 3043.859645] ibmvscsis: Leaving handle_crq: schedule_q empty 0, flags 0x0,
state 0x10
[ 3043.859649] ibmvscsis: calling submit_cmd, se_cmd c0000000fba7bdb0, lun 0x1,
cdb 0xa3, attr:0
[ 3043.859652] ibmvscsis/3000000e: Unsupported SCSI Opcode 0xa3, sending
CHECK_CONDITION.
[ 3043.859655] -----[ Storage Engine Exception for cmd: c0000000fba7bdb0
ITT: 0xc084280b000000c0 CDB: 0xa3
[ 3043.859657] -----[ i_state: 0 t_state: 0 sense_reason: 2
[ 3043.859659] -----[ CMD_T_ACTIVE: 0 CMD_T_STOP: 0 CMD_T_SENT: 0
[ 3043.859661] Incremented dev->dev_cur_ordered_id: 25312 for SIMPLE,
simple_cmd:-5
[ 3043.859664] ibmvscsis: queue_status c0000000fba7bdb0
[ 3043.859666] ibmvscsis: build_resp: cmd c0000000fba7bda0, scsi status 2
[ 3043.859672] ibmvscsis: release_cmd c0000000fba7bdb0, flags 0
[ 3043.859673] ibmvscsis: send_messages cmd c0000000fba7bda0
[ 3043.859679] ibmvscsis: send_messages: tag 0xc084280b000000c0, rc 0
[ 3043.859712] ibmvscsis: got interrupt
[ 3043.859718] ibmvscsis: copy_crq: ioba 0x18014900, init_time 0x17760a1d009
[ 3043.859720] ibmvscsis: srp_cmd tag: 13835058055469368984 (0xc00000000b288698)
[ 3043.859723] ibmvscsis: handle_crq, reenabling interrupts
[ 3043.859725] ibmvscsis: Leaving handle_crq: schedule_q empty 0, flags 0x0,
state 0x10
[ 3043.859729] ibmvscsis: calling submit_cmd, se_cmd c0000000fba7c048, lun 0x1,
cdb 0x12, attr:0
[ 3043.859733] Added HEAD_OF_QUEUE for CDB: 0x12
[ 3043.859736] Incremented dev_cur_ordered_id: 25313 for HEAD_OF_QUEUE
[ 3043.859738] ibmvscsis: queue_data_in, se_cmd c0000000fba7c048, length 0xc
[ 3043.859742] ibmvscsis: rdma: dir 2, bytes 0xc
[ 3043.859744] data:00 00 00 08 00 80 83 86 b0 b1 b2 b3
[ 3043.859752] ibmvscsis: release_cmd c0000000fba7c048, flags 0
[ 3043.859754] ibmvscsis: send_messages cmd c0000000fba7c038
[ 3043.859760] ibmvscsis: send_messages: tag 0x9886280b000000c0, rc 0
[ 3043.859882] ibmvscsis: got interrupt
[ 3043.859888] ibmvscsis: copy_crq: ioba 0x18014a00, init_time 0x17760a323f4
[ 3043.859890] ibmvscsis: srp_cmd tag: 13835058055469369456 (0xc00000000b288870)
[ 3043.859893] ibmvscsis: handle_crq, reenabling interrupts
[ 3043.859895] ibmvscsis: Leaving handle_crq: schedule_q empty 0, flags 0x0,
state 0x10
[ 3043.859899] ibmvscsis: calling submit_cmd, se_cmd c0000000fba7c2e0, lun 0x1,
cdb 0x0, attr:0
[ 3043.859902] Incremented dev->dev_cur_ordered_id: 25314 for SIMPLE,
simple_cmd:-5
[ 3043.859904] ibmvscsis: queue_status c0000000fba7c2e0
[ 3043.859910] ibmvscsis: release_cmd c0000000fba7c2e0, flags 0
[ 3043.859912] ibmvscsis: send_messages cmd c0000000fba7c2d0
[ 3043.859918] ibmvscsis: send_messages: tag 0x7088280b000000c0, rc 0
[ 3043.859946] ibmvscsis: got interrupt
[ 3043.859951] ibmvscsis: copy_crq: ioba 0x18014b00, init_time 0x17760a3a336
[ 3043.859954] ibmvscsis: srp_cmd tag: 13835058055469369928 (0xc00000000b288a48)
[ 3043.859958] ibmvscsis: handle_crq, reenabling interrupts
>From this trace you can see that on a command with Unsupported SCSI Opcode 0xa3
TCM decrements simple_cmds, but since I forced all my commands sent into
TCM to be of attribute TCM_SIMPLE_TAG no commands ever hung, but if I allow
other Tags into target_submit_cmd then it will hang.
2.5.4 (Apple Git-61)
--
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
