From patchwork Mon Feb 27 16:59:59 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Omar Sandoval X-Patchwork-Id: 9593607 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 413A260471 for ; Mon, 27 Feb 2017 17:00:43 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 31E4228488 for ; Mon, 27 Feb 2017 17:00:43 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 2698128490; Mon, 27 Feb 2017 17:00:43 +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 9404128488 for ; Mon, 27 Feb 2017 17:00:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751173AbdB0RAm (ORCPT ); Mon, 27 Feb 2017 12:00:42 -0500 Received: from mail-pf0-f169.google.com ([209.85.192.169]:36761 "EHLO mail-pf0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750971AbdB0RAl (ORCPT ); Mon, 27 Feb 2017 12:00:41 -0500 Received: by mail-pf0-f169.google.com with SMTP id 89so5215517pfi.3 for ; Mon, 27 Feb 2017 09:00:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osandov-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=fa/4YROjkBcsr7DN7RwbXAqI0XFEsgzBlzYUZVg+pYo=; b=HP1O2WhIlmbyfGfSp2su97ZRfteB34T+8aWzb2opJQpB5K/YLP4gd01AtdMdqrBAQR EUqKaepv+fXa5jIDOlmXLB0qgm6VYD7vIR3BikdxdTVrHvFboO75AgDdNicEDIr+/UXi FLIrUn5M0gKWnqjQnsgMeis3Pe1LxRUC4+m5DGBqe0kYBp15V/4H8CXIi+0fvJjzFgWl ucUUKPk2L/LfbqYjFS/maaqHhdkw+nk/h1mtwka2uIVNAFuxZZV6hdLNmgXkP/OeiGvM KH0ozcTL3jOuJslSdkQFzxVzat+DnfaQ0Q4Qp/dbPRvXLFia3WoZS+J/1LF9DtvzJykS apeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=fa/4YROjkBcsr7DN7RwbXAqI0XFEsgzBlzYUZVg+pYo=; b=Ct2AQXi8sxaA/RTnPyCqr27Na0SG4s8W70BxkYuw3dbkKv4oyGqGI7KoJyySCM8uay wV3KtzbwFEkjBdJJv/q8E7xB2alcSmN+w5I1o0cQXzIM4rsaNBEZhxaB0v1+lbpoML5H wnk/zV1zd2D23vOCO5Jm0JbhBVPAai8ncW5bZsy8kpUURgf/V0zlFOHr4pUlm4f8xavy vW0TnMkzweMQI4x0J5oGsKKf/TsRVWxwy7jfdK8dQZ46agMnjZ+BMP7w0dk9TGfgIw5o ZwlTtVonnkm5pSxPxm+hY+6vtg+L7+djcgTIyqvO7fvie9ZuzzCtrWfTIQx3s8bYzWf5 8w3g== X-Gm-Message-State: AMke39nFwGzpQJSqfofIrNahMPVnriEj6XLThjeZJQYuKfEA+twcQI6TT8t8HzHaQ4IEFmy6 X-Received: by 10.98.159.80 with SMTP id g77mr22089351pfe.34.1488214840305; Mon, 27 Feb 2017 09:00:40 -0800 (PST) Received: from vader ([2620:10d:c090:180::93d5]) by smtp.gmail.com with ESMTPSA id r17sm31922178pgg.19.2017.02.27.09.00.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Feb 2017 09:00:39 -0800 (PST) Date: Mon, 27 Feb 2017 08:59:59 -0800 From: Omar Sandoval To: Sagi Grimberg Cc: Jens Axboe , linux-block@vger.kernel.org, linux-nvme@lists.infradead.org Subject: Re: [PATCH 2/2] blk-mq: make sure to back-assign the request to rq_map in blk_mq_alloc_request_hctx Message-ID: <20170227165959.GD10715@vader> References: <1488209781-1084-1-git-send-email-sagi@grimberg.me> <1488209781-1084-2-git-send-email-sagi@grimberg.me> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1488209781-1084-2-git-send-email-sagi@grimberg.me> User-Agent: Mutt/1.8.0 (2017-02-23) 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 Mon, Feb 27, 2017 at 05:36:21PM +0200, Sagi Grimberg wrote: > Otherwise we won't be able to retrieve the request from > the tag. > > Signed-off-by: Sagi Grimberg > --- > block/blk-mq.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/block/blk-mq.c b/block/blk-mq.c > index d84c66fb37b7..9611cd9920e9 100644 > --- a/block/blk-mq.c > +++ b/block/blk-mq.c > @@ -312,6 +312,7 @@ struct request *blk_mq_alloc_request_hctx(struct request_queue *q, int rw, > ret = -EWOULDBLOCK; > goto out_queue_exit; > } > + alloc_data.hctx->tags->rqs[rq->tag] = rq; > > return rq; > > -- > 2.7.4 This one I think is a little bit cleaner if we just push that assignment into __blk_mq_alloc_request() like this (again, compile tested only): Looking a little closer at the caller, though, this is kind of weird: struct request *nvme_alloc_request(struct request_queue *q, struct nvme_command *cmd, unsigned int flags, int qid) { unsigned op = nvme_is_write(cmd) ? REQ_OP_DRV_OUT : REQ_OP_DRV_IN; struct request *req; if (qid == NVME_QID_ANY) { req = blk_mq_alloc_request(q, op, flags); } else { req = blk_mq_alloc_request_hctx(q, op, flags, qid ? qid - 1 : 0); } if (IS_ERR(req)) return req; req->cmd_flags |= REQ_FAILFAST_DRIVER; nvme_req(req)->cmd = cmd; return req; } In the "any" case, we allocate a request with a scheduler tag and go through the scheduler as usual. In the hctx case, we're getting a request with a driver tag, meaning we go through the blk_mq_sched_bypass_insert() path when we run the request. There's nothing really wrong about that, it just seems weird. Not sure if it's weird enough to act on :) diff --git a/block/blk-mq-sched.c b/block/blk-mq-sched.c index 98c7b061781e..7267c9c23529 100644 --- a/block/blk-mq-sched.c +++ b/block/blk-mq-sched.c @@ -135,8 +135,6 @@ struct request *blk_mq_sched_get_request(struct request_queue *q, rq = __blk_mq_alloc_request(data, op); } else { rq = __blk_mq_alloc_request(data, op); - if (rq) - data->hctx->tags->rqs[rq->tag] = rq; } if (rq) { diff --git a/block/blk-mq.c b/block/blk-mq.c index 9e6b064e5339..b4cf9dfa926b 100644 --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -234,6 +234,7 @@ struct request *__blk_mq_alloc_request(struct blk_mq_alloc_data *data, } rq->tag = tag; rq->internal_tag = -1; + data->hctx->tags->rqs[rq->tag] = rq; } blk_mq_rq_ctx_init(data->q, data->ctx, rq, op);