From patchwork Mon Mar 27 12:06:55 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ming Lei X-Patchwork-Id: 9646471 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 EE44C602C8 for ; Mon, 27 Mar 2017 12:07:58 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E52BF27F07 for ; Mon, 27 Mar 2017 12:07:58 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id DA26427F4B; Mon, 27 Mar 2017 12:07:58 +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.5 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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 D19A128307 for ; Mon, 27 Mar 2017 12:07:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752008AbdC0MHq (ORCPT ); Mon, 27 Mar 2017 08:07:46 -0400 Received: from mail-pg0-f67.google.com ([74.125.83.67]:36704 "EHLO mail-pg0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752744AbdC0MHl (ORCPT ); Mon, 27 Mar 2017 08:07:41 -0400 Received: by mail-pg0-f67.google.com with SMTP id 81so12369280pgh.3 for ; Mon, 27 Mar 2017 05:07:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=K6Vf4Q7+0eK/PtTEpNfWkPMxoFZA+uli8VJ3PaU2438=; b=NOYUHdcSDd25Wa7EXCJpfFDtXz0IQcxL/TFP/3s49EvM0+xRCngvb/vTqvtWUG4Hze HLJMlGZwVJ/IMpbSskOOmRZm4Y7gW5H0uS5WXuh5kWeixmcHK7iRb0qW/1U9bTcou+8c 8mu0fD1ExrAsGEpfHi5xzb1ZDuDlk3FX8gziUVfvhBbQ/KKuqm9c3A12MJecKJDyskGO bh6fYRzjvtUnSpI0tq+WOSbWOTXQphU93PNr/4+ey+9ujCOOMc73b9f3/6rwcSBGbYex mnCEKqm3Rmc/lnJqZj26atgXSNJWY/WLEoY1m8UuI1D23FEG8d4d4zTpbZyCHnk2fgDa NqMg== 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; bh=K6Vf4Q7+0eK/PtTEpNfWkPMxoFZA+uli8VJ3PaU2438=; b=cKozWVUFOrKMc6Frwxlp3zS0NL5ge/xp0GU4W32c3uycwoBLOQGHRG2tsEDvhTSwMe y0cacOO1rveJshivGHjSPNmfK05BBQfwq527/tgPWF3hxz7sbjinkJkD0SpXTzI67kDr XFh61D+nozVLP/eMEdaRsX6ZV+BV/ctExPJpNLCvwNlGGW0l1TJ7IiI0ogjc28Z5UoWT r1BM7XHUyev6xHOzw1r9C7CyUSx6Nh28/w0HIBoCfUZmI4X5EPqs4I7IASTzvM+WPew4 QdG+jz29PcP52ifyLR+W1JWFCF/czUHCBNozhvVagnsq5KmX9JCsNJQ6xLQry12l3XEE lKYw== X-Gm-Message-State: AFeK/H3djLyXvsO2nD93z753SmFt9GK8mdBnvE4JPNuoEhyngtLnfHziXcYgvpjtARnfbw== X-Received: by 10.98.197.133 with SMTP id j127mr24531084pfg.238.1490616431713; Mon, 27 Mar 2017 05:07:11 -0700 (PDT) Received: from localhost (li405-222.members.linode.com. [106.187.53.222]) by smtp.gmail.com with ESMTPSA id z21sm885885pgc.53.2017.03.27.05.07.10 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 27 Mar 2017 05:07:10 -0700 (PDT) From: Ming Lei To: Jens Axboe , linux-block@vger.kernel.org, Christoph Hellwig Cc: Bart Van Assche , Hannes Reinecke , Ming Lei Subject: [PATCH v3 1/4] blk-mq: comment on races related with timeout handler Date: Mon, 27 Mar 2017 20:06:55 +0800 Message-Id: <20170327120658.29864-2-tom.leiming@gmail.com> X-Mailer: git-send-email 2.9.3 In-Reply-To: <20170327120658.29864-1-tom.leiming@gmail.com> References: <20170327120658.29864-1-tom.leiming@gmail.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 This patch adds comment on two races related with timeout handler: - requeue from queue busy vs. timeout - rq free & reallocation vs. timeout Both the races themselves and current solution aren't explicit enough, so add comments on them. Cc: Bart Van Assche Reviewed-by: Hannes Reinecke Signed-off-by: Ming Lei Reviewed-by: Johannes Thumshirn --- block/blk-mq.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/block/blk-mq.c b/block/blk-mq.c index c212b9644a9f..b36f0481ba0e 100644 --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -523,6 +523,15 @@ void blk_mq_start_request(struct request *rq) } EXPORT_SYMBOL(blk_mq_start_request); +/* + * When we reach here because queue is busy, REQ_ATOM_COMPLETE + * flag isn't set yet, so there may be race with timeout hanlder, + * but given rq->deadline is just set in .queue_rq() under + * this situation, the race won't be possible in reality because + * rq->timeout should be set as big enough to cover the window + * between blk_mq_start_request() called from .queue_rq() and + * clearing REQ_ATOM_STARTED here. + */ static void __blk_mq_requeue_request(struct request *rq) { struct request_queue *q = rq->q; @@ -696,6 +705,19 @@ static void blk_mq_check_expired(struct blk_mq_hw_ctx *hctx, if (!test_bit(REQ_ATOM_STARTED, &rq->atomic_flags)) return; + /* + * The rq being checked may have been freed and reallocated + * out already here, we avoid this race by checking rq->deadline + * and REQ_ATOM_COMPLETE flag together: + * + * - if rq->deadline is observed as new value because of + * reusing, the rq won't be timed out because of timing. + * - if rq->deadline is observed as previous value, + * REQ_ATOM_COMPLETE flag won't be cleared in reuse path + * because we put a barrier between setting rq->deadline + * and clearing the flag in blk_mq_start_request(), so + * this rq won't be timed out too. + */ if (time_after_eq(jiffies, rq->deadline)) { if (!blk_mark_rq_complete(rq)) blk_mq_rq_timed_out(rq, reserved);