4.16-stable review patch. If anyone has any objections, please let me know.
------------------ From: Tejun Heo <[email protected]> commit bc6d65e6dc89c3b7ff78e4ad797117c122ffde8e upstream. Request abortion is performed by overriding deadline to now and scheduling timeout handling immediately. For the latter part, the code was using mod_timer(timeout, 0) which can't guarantee that the timer runs afterwards. Let's schedule the underlying work item directly instead. This fixes the hangs during probing reported by Sitsofe but it isn't yet clear to me how the failure can happen reliably if it's just the above described race condition. Signed-off-by: Tejun Heo <[email protected]> Reported-by: Sitsofe Wheeler <[email protected]> Reported-by: Meelis Roos <[email protected]> Fixes: 358f70da49d7 ("blk-mq: make blk_abort_request() trigger timeout path") Cc: [email protected] # v4.16 Link: http://lkml.kernel.org/r/CALjAwxh-PVYFnYFCJpGOja+m5SzZ8Sa4J7ohxdK=r8nyof-...@mail.gmail.com Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> --- block/blk-timeout.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/block/blk-timeout.c +++ b/block/blk-timeout.c @@ -165,7 +165,7 @@ void blk_abort_request(struct request *r * No need for fancy synchronizations. */ blk_rq_set_deadline(req, jiffies); - mod_timer(&req->q->timeout, 0); + kblockd_schedule_work(&req->q->timeout_work); } else { if (blk_mark_rq_complete(req)) return;
