On 1/31/17 2:46 PM, Mike Christie wrote:
On 01/30/2017 03:42 PM, Bart Van Assche wrote:
On Thu, 2017-01-26 at 09:31 -0800, Christoph Hellwig wrote:
- queue_work(cmd->se_dev->tmr_wq, &cmd->work);
+ if (cmd->se_dev)
+ queue_work(cmd->se_dev->tmr_wq, &cmd->work);
+ else
+ schedule_work(&cmd->work);
This looks suspicious. se_dev->tmr_wq has the WQ_MEM_RECLAIM flag set, so
it always has a rescuer thread available, while the generic system work
queue is just a best effort. Additional a unbound wq with max_active of
guarantees strict execution ordering. I don't even know if the code
relies on this fact, but changing it should require an explanation of why
that change is fine.
Hello Christoph,
Maybe I overlooked something but I haven't found any clause in SAM-5 that
specifies in which order task management functions should be executed. But
I will add a comment in the code that explains this.
Does it depend on the transport?
I am not sure if it is the same thing, but 6.3.3 in SAM says a LU RESET
would need to terminate all other TMFs that were executing. And for
iscsi, a LU RESET and ABORT TASK SET with a cmd sequence number N is
supposed to terminate tasks and TMFs with cmd sequence numbers N - 1,
and iscsi also says that if a TMF has terminated a task/TMF then the
target cannot send responses for it.
So I think we have execute them in order or make it look like they did.
The drain call does though right?
--
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
Most of the cases you cite specify interactions between a TMF and
commands, not other TMFs (except for the LU Reset case).
More specifically, section 4.4.3 in SAM says "The order in which task
management requests are processed is not specified by the SCSI
architecture model. The SCSI architecture model does not require
in-order delivery of task management requests or processing by the task
manager in the order received."
--
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
