From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754573AbeDBWGF (ORCPT ); Mon, 2 Apr 2018 18:06:05 -0400 Received: from mail-yb0-f194.google.com ([209.85.213.194]:45866 "EHLO mail-yb0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754429AbeDBWGC (ORCPT ); Mon, 2 Apr 2018 18:06:02 -0400 X-Google-Smtp-Source: AIpwx49kF5lQSZRk33UBi6o0g+jMCU29lARMCqiPXQfHZEjhXYLyWT4OhEYcgKKLyiYXWmZK5Xcrmg== Date: Mon, 2 Apr 2018 15:05:58 -0700 From: Tejun Heo To: Meelis Roos Cc: Bartlomiej Zolnierkiewicz , Linux Kernel list , linux-ide@vger.kernel.org, linux-block@vger.kernel.org Subject: Re: 4.16-rc2+git: pata_serverworks: hanging ata detection thread on HP DL380G3 Message-ID: <20180402220558.GK388343@devbig577.frc2.facebook.com> References: <1597679.yzYZqmDdA5@amdc3058> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, Meelis. Can you please verify whether the following patch fixes the problem? Thanks. Subject: blk-mq: Directly schedule q->timeout_work when aborting a request 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 Reported-by: Sitsofe Wheeler Reported-by: Meelis Roos --- block/blk-timeout.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/block/blk-timeout.c b/block/blk-timeout.c index a05e367..f0e6e41 100644 --- a/block/blk-timeout.c +++ b/block/blk-timeout.c @@ -165,7 +165,7 @@ void blk_abort_request(struct request *req) * 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;