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
