From patchwork Wed Feb 28 00:56:42 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Omar Sandoval X-Patchwork-Id: 10246445 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 780EF60208 for ; Wed, 28 Feb 2018 00:56:52 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6A38828B2B for ; Wed, 28 Feb 2018 00:56:52 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 5E7B128B2D; Wed, 28 Feb 2018 00:56:52 +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.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_HI 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 072D328B2C for ; Wed, 28 Feb 2018 00:56:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751788AbeB1A4v (ORCPT ); Tue, 27 Feb 2018 19:56:51 -0500 Received: from mail-pf0-f196.google.com ([209.85.192.196]:40391 "EHLO mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751789AbeB1A4u (ORCPT ); Tue, 27 Feb 2018 19:56:50 -0500 Received: by mail-pf0-f196.google.com with SMTP id m5so318606pff.7 for ; Tue, 27 Feb 2018 16:56:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osandov-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :in-reply-to:references; bh=Y23TCk3xS7bskNzTkobPW9R/xvis2lyFC2dpb1aC2OM=; b=lom1ahpdJ+TTWl2HnDO7jZkclSszuy81Kl5k05p5P7HZSysH6l/RLg49PpysjPgkAb RLC8oHcaPAoL+pyB6LyiMGJNUlBBzX/S3W7pekKYT/wxbribqlsTzlevZt4lbg0yr7m/ K84CW28LP8r7xuvW9Usq3hetkfdZhjQWBjUup+oIOaJRl0DIXHcJjcVfYr6kxfxPstqP l3hPJHrMQOcWgDa2eO4fsET7NUeuoRf8S9twuRxrPRFpEFMvtaVCD1BLOngwPyPowxVX idPFW2AcsDpJCimHROVH0jaqggcrXpefnSWEC2K6yi9T3Ra3iN+0ZAoB03Rj/bPEtDhB IwcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:in-reply-to:references; bh=Y23TCk3xS7bskNzTkobPW9R/xvis2lyFC2dpb1aC2OM=; b=VoVAmX5yVYvmMh8OQRfsUXIyklPy5cxWdMeOn0+szLHwDwhrsWpHpHLxvY4ZM7+IxL Yn/xARgZweySbQBXBZU/bAwzaYAflJEZQ+pr1YVja4rrDCKNOiW0IG6vzlHQ/uk3Zg9O ElAGZvY7X16mjUZ4pPpVocPmTriVoHPzgNh2c+Dmch1QxFdEI67kKcK0LAaUF4uJMlG9 vHUAqob/lKpd7qHP8wmXQ8pxsfCRr3FMEtqr1APZAqQUp6EHTv+Z5c0pkhsMDPKQBhj4 FWR0b65DJi0P4HipWvFMKkdtf5UTt1/hhEJVabaDzgok/1l639cOMf7KHDdf1MonRYDN YRxQ== X-Gm-Message-State: APf1xPBLEUtAkvYgyxk8Rx9+H1b89wKrhAtts1YxTZplPI5n6ThOKVwM I6qA5vlM9apncpSeNqigLpzD2xu8I7k= X-Google-Smtp-Source: AH8x225Sots++HWnXhzAMSTJfrR4n956Cy/C+wnrorbmI1ZxumgNwCsd1fDVu21uS3YEi5xv7HCIWg== X-Received: by 10.101.66.1 with SMTP id c1mr12769943pgq.137.1519779409731; Tue, 27 Feb 2018 16:56:49 -0800 (PST) Received: from vader.thefacebook.com ([2620:10d:c090:200::4:ba04]) by smtp.gmail.com with ESMTPSA id z79sm463752pfa.139.2018.02.27.16.56.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Feb 2018 16:56:49 -0800 (PST) From: Omar Sandoval To: linux-block@vger.kernel.org Cc: Jens Axboe , kernel-team@fb.com, Tejun Heo Subject: [PATCH 1/2] block: clear ctx pending bit under ctx lock Date: Tue, 27 Feb 2018 16:56:42 -0800 Message-Id: X-Mailer: git-send-email 2.16.2 In-Reply-To: References: In-Reply-To: References: 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 From: Omar Sandoval When we insert a request, we set the software queue pending bit while holding the software queue lock. However, we clear it outside of the lock, so it's possible that a concurrent insert could reset the bit after we clear it but before we empty the request list. Afterwards, the bit would still be set but the software queue wouldn't have any requests in it, leading us to do a spurious run in the future. This is mostly a benign/theoretical issue, but it makes the following change easier to justify. Signed-off-by: Omar Sandoval --- block/blk-mq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/block/blk-mq.c b/block/blk-mq.c index 357492712b0e..09a57d97ca7f 100644 --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -984,9 +984,9 @@ static bool flush_busy_ctx(struct sbitmap *sb, unsigned int bitnr, void *data) struct blk_mq_hw_ctx *hctx = flush_data->hctx; struct blk_mq_ctx *ctx = hctx->ctxs[bitnr]; - sbitmap_clear_bit(sb, bitnr); spin_lock(&ctx->lock); list_splice_tail_init(&ctx->rq_list, flush_data->list); + sbitmap_clear_bit(sb, bitnr); spin_unlock(&ctx->lock); return true; }