Received: by 2002:a5d:9c59:0:0:0:0:0 with SMTP id 25csp2149142iof; Tue, 7 Jun 2022 21:23:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx2Rb/dfyVm5FxX4EMl+l6v5ADwNdcwHtDMBlzPR3FNp+XHLdOyWoD6wMGJsrgML3KTHSS+ X-Received: by 2002:a63:69c1:0:b0:3fa:e815:a761 with SMTP id e184-20020a6369c1000000b003fae815a761mr27920297pgc.268.1654662208070; Tue, 07 Jun 2022 21:23:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654662208; cv=none; d=google.com; s=arc-20160816; b=vGn1kwwTzCnhi3EUVClEimwJzq0+KvQgbnUbzx/5iXqXYSsAsec/S2EfE1rK/9km1w D/rhYXjB1YDmQ98MOpzN0cfCCFIidSwyE0Iy+LdkWuAI0VAWmTGP2xp9nIrkw8TzNVFH W2PJLNJRuG1W49V2e/5znAMOXkuuBkvK2omobMPFn89P5xKSuLqj9rI+/rWy+Cnyu52b mRplwees+eGlsO4VqtrWb8DReFI/YYbgnFrLKv7q0DzOE3fDf4p6zdNhxXzppgwz+POu jtO+jKYnwbhKvV9lNZ0gQNbqFUNd3DX5HWxA8+Av3Blcrlus7y3YqYWbmepw1RO4VywF IlNQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=VyzAJUadUm859LbqItXovozMWbOmvKYwJkv6T6+OH8E=; b=LGWNpT7KG4R9DoLrorZYaHfNAEnW4/oC+UyDg00XCIvwt4rM1bFVJ9xxT4rNppSd/Z 459KuIIegKc+IAWaoPvUziEGquIB8iBUkkMp75v2d8h2wwXWdJlAPlZDh1Nz8GliXUGf LvueDDLqOBreFS9jl8VEJOq746+T00lf5XVD5SsuPoNmCb4FMjkY37XuokR1vY5rEWdh P3LFlJxaLw6NJlEwFY9sott1gsG/+r1GypG8RxXKvEo7j9yBKU/rQy1M+yiPgVa5YjP/ IsbTxGiytX0KTV6jA7fPQAujA98T+ATVw+Fz9k6y6vlj6ON0nBTOEoVcq1l3ON/2hoMX Z/zg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=Q2llcPh1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id v1-20020a62a501000000b0051b9771d617si24464713pfm.179.2022.06.07.21.23.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jun 2022 21:23:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=Q2llcPh1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 4166343E83E; Tue, 7 Jun 2022 21:10:59 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376655AbiFGUtQ (ORCPT + 99 others); Tue, 7 Jun 2022 16:49:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39596 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357909AbiFGTrZ (ORCPT ); Tue, 7 Jun 2022 15:47:25 -0400 Received: from sin.source.kernel.org (sin.source.kernel.org [IPv6:2604:1380:40e1:4800::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DE5FE6EB28; Tue, 7 Jun 2022 11:19:16 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id BEF13CE2428; Tue, 7 Jun 2022 18:19:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D1FA8C385A5; Tue, 7 Jun 2022 18:19:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654625953; bh=TLR9qUvj/0sLCsIOv3xfnFG3iF0rfWWP61ap7+Ebwaw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Q2llcPh1lhM/ldmy6BQoro7akY4EYTkAuO3FlCJ2qQemGsxcx9jAxtDu1G5V7pHeP uzTAG8Cd+YZc2F6UDSz2TiPhIzgE0xIW/B/L2jM2Zwd4B0XCE0bq1SEsmSL0aS+N95 qzRc4fwHgWIP/4c87DXLQT3+PvzocujGYMTb4uWw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Chaitanya Kulkarni , Keith Busch , Christoph Hellwig , Sasha Levin Subject: [PATCH 5.17 167/772] nvme: set non-mdts limits in nvme_scan_work Date: Tue, 7 Jun 2022 18:55:59 +0200 Message-Id: <20220607164953.961594213@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220607164948.980838585@linuxfoundation.org> References: <20220607164948.980838585@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Chaitanya Kulkarni [ Upstream commit 78288665b5d0154978fed431985310cb4f166836 ] In current implementation we set the non-mdts limits by calling nvme_init_non_mdts_limits() from nvme_init_ctrl_finish(). This also tries to set the limits for the discovery controller which has no I/O queues resulting in the warning message reported by the nvme_log_error() when running blktest nvme/002: - [ 2005.155946] run blktests nvme/002 at 2022-04-09 16:57:47 [ 2005.192223] loop: module loaded [ 2005.196429] nvmet: adding nsid 1 to subsystem blktests-subsystem-0 [ 2005.200334] nvmet: adding nsid 1 to subsystem blktests-subsystem-1 <------------------------------SNIP----------------------------------> [ 2008.958108] nvmet: adding nsid 1 to subsystem blktests-subsystem-997 [ 2008.962082] nvmet: adding nsid 1 to subsystem blktests-subsystem-998 [ 2008.966102] nvmet: adding nsid 1 to subsystem blktests-subsystem-999 [ 2008.973132] nvmet: creating discovery controller 1 for subsystem nqn.2014-08.org.nvmexpress.discovery for NQN testhostnqn. *[ 2008.973196] nvme1: Identify(0x6), Invalid Field in Command (sct 0x0 / sc 0x2) MORE DNR* [ 2008.974595] nvme nvme1: new ctrl: "nqn.2014-08.org.nvmexpress.discovery" [ 2009.103248] nvme nvme1: Removing ctrl: NQN "nqn.2014-08.org.nvmexpress.discovery" Move the call of nvme_init_non_mdts_limits() to nvme_scan_work() after we verify that I/O queues are created since that is a converging point for each transport where these limits are actually used. 1. FC : nvme_fc_create_association() ... nvme_fc_create_io_queues(ctrl); ... nvme_start_ctrl() nvme_scan_queue() nvme_scan_work() 2. PCIe:- nvme_reset_work() ... nvme_setup_io_queues() nvme_create_io_queues() nvme_alloc_queue() ... nvme_start_ctrl() nvme_scan_queue() nvme_scan_work() 3. RDMA :- nvme_rdma_setup_ctrl ... nvme_rdma_configure_io_queues ... nvme_start_ctrl() nvme_scan_queue() nvme_scan_work() 4. TCP :- nvme_tcp_setup_ctrl ... nvme_tcp_configure_io_queues ... nvme_start_ctrl() nvme_scan_queue() nvme_scan_work() * nvme_scan_work() ... nvme_validate_or_alloc_ns() nvme_alloc_ns() nvme_update_ns_info() nvme_update_disk_info() nvme_config_discard() <--- blk_queue_max_write_zeroes_sectors() <--- Signed-off-by: Chaitanya Kulkarni Reviewed-by: Keith Busch Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin --- drivers/nvme/host/core.c | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-) diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c index 0abd772c57f0..79ef46356d40 100644 --- a/drivers/nvme/host/core.c +++ b/drivers/nvme/host/core.c @@ -3096,10 +3096,6 @@ int nvme_init_ctrl_finish(struct nvme_ctrl *ctrl) if (ret) return ret; - ret = nvme_init_non_mdts_limits(ctrl); - if (ret < 0) - return ret; - ret = nvme_configure_apst(ctrl); if (ret < 0) return ret; @@ -4160,11 +4156,26 @@ static void nvme_scan_work(struct work_struct *work) { struct nvme_ctrl *ctrl = container_of(work, struct nvme_ctrl, scan_work); + int ret; /* No tagset on a live ctrl means IO queues could not created */ if (ctrl->state != NVME_CTRL_LIVE || !ctrl->tagset) return; + /* + * Identify controller limits can change at controller reset due to + * new firmware download, even though it is not common we cannot ignore + * such scenario. Controller's non-mdts limits are reported in the unit + * of logical blocks that is dependent on the format of attached + * namespace. Hence re-read the limits at the time of ns allocation. + */ + ret = nvme_init_non_mdts_limits(ctrl); + if (ret < 0) { + dev_warn(ctrl->device, + "reading non-mdts-limits failed: %d\n", ret); + return; + } + if (test_and_clear_bit(NVME_AER_NOTICE_NS_CHANGED, &ctrl->events)) { dev_info(ctrl->device, "rescanning namespaces.\n"); nvme_clear_changed_ns_log(ctrl); -- 2.35.1