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. Regarding WQ_MEM_RECLAIM: that flag guarantees that there is at least one execution context regardless of memory pressure. So enabling that flag is essential for any workqueue that executes work inside the memory reclaim path. The only way the above code can be called from inside a block device implementation is if it gets called by the tcm_loop driver. However, I'm not sure anyone is using the tcm_loop driver for another purpose than testing the LIO core and backend drivers? Bart.-- 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
