From patchwork Fri Mar 24 12:36:18 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ming Lei X-Patchwork-Id: 9642777 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 C9F0460327 for ; Fri, 24 Mar 2017 12:36:39 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id C537527F07 for ; Fri, 24 Mar 2017 12:36:39 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id BA1FA28285; Fri, 24 Mar 2017 12:36:39 +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=-7.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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 3800F27F07 for ; Fri, 24 Mar 2017 12:36:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933467AbdCXMgj (ORCPT ); Fri, 24 Mar 2017 08:36:39 -0400 Received: from mail-pf0-f196.google.com ([209.85.192.196]:36806 "EHLO mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932434AbdCXMgh (ORCPT ); Fri, 24 Mar 2017 08:36:37 -0400 Received: by mail-pf0-f196.google.com with SMTP id r137so193538pfr.3 for ; Fri, 24 Mar 2017 05:36:36 -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=fsuEQStiniICDFki1g8jg99tok//1xaBXardTqPKVpGiewV+raSQn8hr7pMAHLLPNA ssvEANmLZYK7Dq+U8kSycfvyYr8U4MD90jy127Mf95fY37VnhEgbosA3Ur5X+xvNIfjT hUBMctOB0VRq5RIvfnb58sde8DOQOhXtfThcrC+7NChEONpFZkggUYJM/UrBx0paSSl0 jHtWI8IjkbN2gR9i92nZ51/DuQdbEI6FEHBtlOFaTaN+pnq8d8uQg5XVks/oL2yMglm2 S9pUHXSZWzm9Lb75pDQESLJAD6i4bcomMKehWMXR0KBZWULIUf2gySAQslR3vJHc5qii TPYg== 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=qY8GpNLzh2V6PLQcX+XPDSnoLlLgbuYkQE+bqE7KCLF0+HuSLch01kLCEl85Ex7tsP nrAhneVgvVyEx+aijCgt6aacf/SnYTNI6HJ/4B/2gvO6cPdJSmRGOC0wK1RwzHNsbt1u WpXOSrDW8OYOByBgBLDAZ0g7GTl5X9baNKMfvynRP4N76SLQGYni3gnZ2awt6RNXiHBb Xm+JrktN+1/DJGO7H9BrGDoWvBLpW0FBaxl5FnSHy20ip8fj/jq5j64yqM+KiTF1RC6W 6Be9Pmld9osjymH0OAPslHovoYVlE70s9g3J/nPRlJs0uuL/YZod6PbtctKBGlpsVfl+ 70QA== X-Gm-Message-State: AFeK/H1e6jx55W0GIvEVsYaV5IiVhhoeDP4R0YYInB4cG8+xTBn/iqRq5CvIc2OpQ2QQ+A== X-Received: by 10.98.144.151 with SMTP id q23mr8859623pfk.51.1490358996192; Fri, 24 Mar 2017 05:36:36 -0700 (PDT) Received: from localhost (li405-222.members.linode.com. [106.187.53.222]) by smtp.gmail.com with ESMTPSA id 78sm4611018pfm.122.2017.03.24.05.36.35 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 24 Mar 2017 05:36:35 -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 v2 1/4] blk-mq: comment on races related with timeout handler Date: Fri, 24 Mar 2017 20:36:18 +0800 Message-Id: <20170324123621.5227-2-tom.leiming@gmail.com> X-Mailer: git-send-email 2.9.3 In-Reply-To: <20170324123621.5227-1-tom.leiming@gmail.com> References: <20170324123621.5227-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 --- 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);