On 05/23/2017 06:48 PM, Bart Van Assche wrote:
> Introduce a function that sends the SCSI status "BUSY" back to the
> initiator.
>
> Signed-off-by: Bart Van Assche <bart.vanassche@xxxxxxxxxxx>
> Reviewed-by: Hannes Reinecke <hare@xxxxxxxx>
> Cc: Christoph Hellwig <hch@xxxxxx>
> Cc: Andy Grover <agrover@xxxxxxxxxx>
> Cc: David Disseldorp <ddiss@xxxxxxx>
> ---
> drivers/target/target_core_transport.c | 10 ++++++++++
> include/target/target_core_fabric.h | 1 +
> 2 files changed, 11 insertions(+)
>
> diff --git a/drivers/target/target_core_transport.c b/drivers/target/target_core_transport.c
> index cfe69c1fc879..c28e3b58150b 100644
> --- a/drivers/target/target_core_transport.c
> +++ b/drivers/target/target_core_transport.c
> @@ -3130,6 +3130,16 @@ transport_send_check_condition_and_sense(struct se_cmd *cmd,
> }
> EXPORT_SYMBOL(transport_send_check_condition_and_sense);
>
> +int target_send_busy(struct se_cmd *cmd)
> +{
> + WARN_ON_ONCE(cmd->se_cmd_flags & SCF_SCSI_TMR_CDB);
> +
> + cmd->scsi_status = SAM_STAT_BUSY;
> + trace_target_cmd_complete(cmd);
> + return cmd->se_tfo->queue_status(cmd);
> +}
Hey,
How are drivers supposed to handler queue_status failures or should that
not happen when this is called?
If it can happen, do they just drop the command? Is the tmr code able to
figure this out? Will it not even be on the sess_cmd_list so would hit
the does not exist tmr abort code path, or will it just sit in
transport_wait_for_tasks? Are drivers supposed to call
transport_handle_queue_full to queue up retrying sending something?
--
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
