From patchwork Thu Apr 20 23:09:42 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jens Axboe X-Patchwork-Id: 9691477 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 B2DFE601D4 for ; Thu, 20 Apr 2017 23:09:50 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A30CD28409 for ; Thu, 20 Apr 2017 23:09:50 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 939ED28477; Thu, 20 Apr 2017 23:09:50 +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.4 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM 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 1E8A428409 for ; Thu, 20 Apr 2017 23:09:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1033714AbdDTXJt (ORCPT ); Thu, 20 Apr 2017 19:09:49 -0400 Received: from mail-io0-f170.google.com ([209.85.223.170]:35524 "EHLO mail-io0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1033665AbdDTXJs (ORCPT ); Thu, 20 Apr 2017 19:09:48 -0400 Received: by mail-io0-f170.google.com with SMTP id r16so87442996ioi.2 for ; Thu, 20 Apr 2017 16:09:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=0wPDg6GptuDpnZZiVpLT2lFheU0+rJDTH+dv4jOsoCs=; b=RKpFTk9j4JZKd2euPbs0ETuIRon1mdHVDrq0p0Gt/YfgRGO9ekXTbQSocxX1jDeGaf LDIrmr0Om2Z2DbUbBgIkt66v2giAYCrU8AxC8rlMUgJ2VE3R3XnUyDQpJxglHtn2ILBi iHUl2j+x7kWcDv3bOw0SD31DmOW3bRPnIZAzAxk5FXghVc78/tB2AF37Xr13uCcYfcvJ 84J00m2buMRjxt/pIRkPod2NFxeIx4LGm5m13Qcprg988VitgYWugDQlrCOK3V9L6xhO 4q2pef5sxpueuVdGn/aPo6NBBlV7Qs2CydPcQRcGOP4HEJQrnQIk6IhJzpZUKbwx0ELW Et5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=0wPDg6GptuDpnZZiVpLT2lFheU0+rJDTH+dv4jOsoCs=; b=X/UWwLZqBb48N/OOAtO6a6JbBtk1HHegKWl8YJtzZfLnn+Jr1fPH0zFytdlLqMpdgT HH5NSVZupP3cGNG4rjxIsftSydxec3q9Yd/Bk60akrXEdMsqHBlt/49eLJ8NYPGxOX8A B5BANZ5vVxvRTjNSIXNdEkIGkSLD0Ear88Trn4RZfqy4rwZl623fw4OApH5mqbf4hbg+ /++MShCuX3D4QVFVCJeqZbgSTqof+KyCDhqcqeXJ0XLpb9Kfu4Wpk+BR2oCYdEnvue/O 4+7kpL3qMS2wWLnGPOpREE9Sx8tGNa5x7SudetbqLkat7iwr77FQZS/VR2QDTmEeqrPi nTIA== X-Gm-Message-State: AN3rC/6tnj7EXRYKeh0K4BFmWM412s00MIEyaf3Pa4ok/I0bz73PoL5J vYIriSv2s+92V8ipD20= X-Received: by 10.99.114.16 with SMTP id n16mr9462303pgc.230.1492729785115; Thu, 20 Apr 2017 16:09:45 -0700 (PDT) Received: from [192.168.1.176] (66.29.164.166.static.utbb.net. [66.29.164.166]) by smtp.gmail.com with ESMTPSA id y184sm12301932pgb.33.2017.04.20.16.09.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Apr 2017 16:09:44 -0700 (PDT) Subject: Re: [PATCH] blk-mq-sched: add might_sleep() check for flush/fua insert To: Bart Van Assche , "linux-block@vger.kernel.org" References: <1492729028.2642.16.camel@sandisk.com> From: Jens Axboe Message-ID: Date: Thu, 20 Apr 2017 17:09:42 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1492729028.2642.16.camel@sandisk.com> 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 On 04/20/2017 04:57 PM, Bart Van Assche wrote: > On Thu, 2017-04-20 at 16:45 -0600, Jens Axboe wrote: >> If we're doing a flush/fua insert, insertion might block on getting >> a driver tag, if can_block == true. Add a might_sleep check for that, >> since we just had a bug like that. This will help us catch a similar >> issue quicker in the future. >> >> diff --git a/block/blk-mq-sched.c b/block/blk-mq-sched.c >> index 9e3c0f92851b..57aec8462e93 100644 >> --- a/block/blk-mq-sched.c >> +++ b/block/blk-mq-sched.c >> @@ -372,6 +372,7 @@ void blk_mq_sched_insert_request(struct request *rq, bool at_head, >> struct blk_mq_hw_ctx *hctx = blk_mq_map_queue(q, ctx->cpu); >> >> if (rq->tag == -1 && op_is_flush(rq->cmd_flags)) { >> + might_sleep_if(can_block); >> blk_mq_sched_insert_flush(hctx, rq, can_block); >> return; >> } > > Hello Jens, > > The above patch looks fine to me. But seeing that patch made me wonder > whether it would be useful to move that might_sleep_if() call into > blk_mq_get_driver_tag() such that if ever an additional call to > blk_mq_get_driver_tag() is added that might sleep would also be covered? Yes, that's not a bad suggestion. Below: From: Jens Axboe Subject: [PATCH] blk-mq: add might_sleep check to blk_mq_get_driver_tag() If the caller passes in wait=true, it has to be able to block for a driver tag. We just had a bug where flush insertion would block on tag allocation, while we had preempt disabled. Ensure that we catch cases like that earlier next time. Signed-off-by: Jens Axboe Reviewed-by: Bart Van Assche diff --git a/block/blk-mq.c b/block/blk-mq.c index 992f09772f8a..dd6e5dd62804 100644 --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -866,6 +866,8 @@ bool blk_mq_get_driver_tag(struct request *rq, struct blk_mq_hw_ctx **hctx, .flags = wait ? 0 : BLK_MQ_REQ_NOWAIT, }; + might_sleep_if(wait); + if (rq->tag != -1) goto done;