From patchwork Mon Apr 2 22:05:58 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tejun Heo X-Patchwork-Id: 10320421 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id EDDE260116 for ; Mon, 2 Apr 2018 22:06:04 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D521F288EE for ; Mon, 2 Apr 2018 22:06:04 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id C95F928A45; Mon, 2 Apr 2018 22:06:04 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 56420288EE for ; Mon, 2 Apr 2018 22:06:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754499AbeDBWGC (ORCPT ); Mon, 2 Apr 2018 18:06:02 -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 Received: by mail-yb0-f194.google.com with SMTP id k199-v6so5499404ybk.12; Mon, 02 Apr 2018 15:06:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=GzS5TIyOTslPHZxsVEA3O3IqJtcF1PLfAAiLPyWxBWo=; b=uHWnjk3FROyWWL8qtiaI5YUP3NiyEUDcShp8gINKzP2u9blc7PFlFU6YwejSZddxCf GUD1uQuvmQfd1tLoJ+0jAa6RC2QBRnfid/XFTOjwbSjSV69mj+QA/FSCy70Fai7YB1dt vottdskpNxAmpcpVM03I5UNmAOj92QTS1zsOHVv9+ePuzWlnOyiYPsf1DpCrrtw06C35 YbFMtrbFvTcC8musvj0msyf108ZWNHbi4xQKMpn6D8XckyPmdJqzwpG3hdtcP0U/Hlxw /NVyw9yuC/Mj0qsNzB9YCDvXbrp8JaW/+ZlkLdv6C4SeMcEQnzjtHWQxzCzBLudFgkJF MZ8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=GzS5TIyOTslPHZxsVEA3O3IqJtcF1PLfAAiLPyWxBWo=; b=mU7qxhdLMUxT0XKsA4EgiMOl/Zxjvxaew5UWVb7qPHbzTFfsLQ7jlqCf4xgEskjNHm de3bYG8dik9jtd5A9EhagsuR6iqvQplKQi1Mlpgmt30+NPPLABMPvyqdnDuTED9aCtk7 hCUky0ci3Krgu5r9pPsuqrRODhVm1yClISSbBaSlykpfJt15W7idCLw/7xfSw2XfvhGl HxzDcMaZdjpcv1rlFRWGnCy2xvwZdmWiE8tAp8fX7K1JF72vXHtf2hbDuBXs198gSleb MiTa3nqCXKBfrVNygglzVI86vMDPpHUogiNhScKHccU/nobt4t+8E9WWENFMM1uM2+0V xZ1g== X-Gm-Message-State: ALQs6tBN5tZ+CByu+g1SK8pQ4Hlq3jOypmoDE1y/dW6IK8j4mqZ1vFPu hXOrPo0NuYieoQy6z57yZBo= X-Google-Smtp-Source: AIpwx49kF5lQSZRk33UBi6o0g+jMCU29lARMCqiPXQfHZEjhXYLyWT4OhEYcgKKLyiYXWmZK5Xcrmg== X-Received: by 2002:a25:ea06:: with SMTP id p6-v6mr5820749ybd.441.1522706761248; Mon, 02 Apr 2018 15:06:01 -0700 (PDT) Received: from localhost ([2620:10d:c091:180::1:23de]) by smtp.gmail.com with ESMTPSA id n62sm604679ywe.4.2018.04.02.15.06.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Apr 2018 15:06:00 -0700 (PDT) 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-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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;