From patchwork Fri Mar 17 09:57:10 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ming Lei X-Patchwork-Id: 9630189 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 8CCA760249 for ; Fri, 17 Mar 2017 10:02:21 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 63A9C205A4 for ; Fri, 17 Mar 2017 10:02:21 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 5886820700; Fri, 17 Mar 2017 10:02:21 +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=unavailable 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 54865205FC for ; Fri, 17 Mar 2017 10:02:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751179AbdCQKCF (ORCPT ); Fri, 17 Mar 2017 06:02:05 -0400 Received: from mail-pg0-f67.google.com ([74.125.83.67]:36710 "EHLO mail-pg0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751314AbdCQJ7X (ORCPT ); Fri, 17 Mar 2017 05:59:23 -0400 Received: by mail-pg0-f67.google.com with SMTP id 81so1151910pgh.3; Fri, 17 Mar 2017 02:57:29 -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=gdxmURpIHePYWgL5h4rOYLnSnQ5HergLmTWSy8TXgqI=; b=CebFXKmCX8oVrvXRmuRFF9Zit9EBIs6yHJLvGBqQHuY18gaA+PjftYNqMWWEt7MLAF 9lQGjHiBsKD5YzPvy6NSHJOnV6SPRiOeCORAFnHVW2jSZWB8ThJxSdl+XONS2+LpV5IO dqtT4lXW93oucL9/I70J7dVZRlARtElXpLsN4DKLWq+a0TDhK7erRGzHxauGXwYTtlhO t3ShrYg+7uBRwHlfUPI1aHXmqS3VeytroT1kKiUngJfXIJ/F0gxX5Jve4+rc4CjYMZWo ffw0BEPEmZM57QJKgeoYuXYkLRdj1LH3d3jkx/fWF0X2Os+pHu1FPkOXemox/3YaszKD +l+A== 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=gdxmURpIHePYWgL5h4rOYLnSnQ5HergLmTWSy8TXgqI=; b=fK5j0pB+p+KWqYZhjjhM0OdUfTcJtQ9a4dFjN84hHH0a0AJlbJrp1I1TTpV+R/hmcX b8+mxSWdEUkGPmoq/GI/YiG5F8j8SQNeNbA/uqodhYBxjYq/KI+DvpfJy4Qe9A7dEiOW ZWia676jB/lcBVU7+82R4rOHLZDcQhzvxtT3k8X61Epe+FXZxsa7j0K9MqQ7Gno37ypK mSh4yk2C2nFWC+YzTdEDiUY2KrPp4bqAXBvm3Rcr9uxbaIuhUH22IrHn4oz6TWLj/hJ6 nJBgYOnRyWhmznU/Izm6lx9G/5nBHo8oesKyLwOVzg2FN5qs0EJWh9s7NOwldfXyQyXA VujA== X-Gm-Message-State: AFeK/H0T3hjXIql4vgfn7AfkJXlNbx+lfzqyROuWoBckl37iwfLKGm3ovfTNSRfNnTGpew== X-Received: by 10.98.155.28 with SMTP id r28mr15353919pfd.212.1489744649078; Fri, 17 Mar 2017 02:57:29 -0700 (PDT) Received: from localhost ([103.192.224.52]) by smtp.gmail.com with ESMTPSA id j62sm15759869pgc.54.2017.03.17.02.57.28 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 17 Mar 2017 02:57:28 -0700 (PDT) From: Ming Lei To: Jens Axboe , linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, Christoph Hellwig Cc: Yi Zhang , Bart Van Assche , Ming Lei Subject: [PATCH v1 2/3] blk-mq: comment on races related with timeout handler Date: Fri, 17 Mar 2017 17:57:10 +0800 Message-Id: <20170317095711.5819-3-tom.leiming@gmail.com> X-Mailer: git-send-email 2.9.3 In-Reply-To: <20170317095711.5819-1-tom.leiming@gmail.com> References: <20170317095711.5819-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 Signed-off-by: Ming Lei Reviewed-by: Hannes Reinecke --- block/blk-mq.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/block/blk-mq.c b/block/blk-mq.c index 08a49c69738b..7068779d3bac 100644 --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -527,6 +527,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 sitation, 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; @@ -700,6 +709,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);