From patchwork Sat Oct 22 07:19:01 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 7639 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4242:0:0:0:0:0 with SMTP id s2csp1107638wrr; Sat, 22 Oct 2022 01:41:35 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4hoHwhYPzDAS8nd60KM37nGRlnroAM/6gRR2BjeWoBRHrGNuC18Td1lXahMth7IX+w432u X-Received: by 2002:a05:6402:35cc:b0:45d:442:1765 with SMTP id z12-20020a05640235cc00b0045d04421765mr21446019edc.51.1666428095187; Sat, 22 Oct 2022 01:41:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666428095; cv=none; d=google.com; s=arc-20160816; b=ZsYTziRRh2w1oanzcXaJmkpGzP9UB88IdGvqmC2TP1rSbu/6ILZjq0oVM0jZ0k4Nay Vd/k7PXPdkYLEoc8/YkJLHBz6ksMhGlyWTQ+qACdpjOiy9BCjv5iz2/4kBzKqWUY+kmy D6qRTaRewDrx3yY0pgJAYqLwk7okRMe2tUaV7tDtuMn/f8heRDjs2UByiTXgxjOR7ak4 Kcosjkq6dXs7kYvzT0PVfs8Mxf77w4tgz92U1zNm01K9KLYHbJX1M7AHtzwqsA0wLcCE UfMRyqp1k+MDpcQ4BbU8r++iy4znAz8zgz+z5Ogf7fjjEeEBGBWphTmFGRpHTm12Y1TK e5bw== 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=TW826vAKXuOrryw/6+DW8pbOkbYkeAdYmnPeHLAfYP0=; b=UkMVNwzW4/+zXjB/GGftvyHXPwPQidGUNDkndHgTqdYSQ6Vc14GnCH4YZQzd9nyOYn eIYc7VtU+rhoqhiYrP9z4w8fiKSOG1n07TGrHN21SNMKRG8Yi06nqf/dkOFx6dgvajH0 MR8/k6a5ir8qhLjWbGRnFMPw8lnhVqTui6EH7uZdoFrJDNOnR/0vp9mtM+wdBHLCdsNw x1/2TIujOuzHwj5neVw65YaosKpZygjjhR+8MzC4tdjFGRrmSY+QDYjPiIfGMmf/IPR2 jIW4Iwra6Jwf/gyHpKCubRqbQWeTwaKPWT50XijqqE/7P5qXGRUodhBdMcyJu4tdx+EX Q88Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="v/xdFGfp"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id bc13-20020a056402204d00b0046121c10e6fsi4895191edb.101.2022.10.22.01.41.09; Sat, 22 Oct 2022 01:41:35 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="v/xdFGfp"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234437AbiJVIiP (ORCPT + 99 others); Sat, 22 Oct 2022 04:38:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59136 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234051AbiJVIca (ORCPT ); Sat, 22 Oct 2022 04:32:30 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B31592D12AA; Sat, 22 Oct 2022 01:03:35 -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 dfw.source.kernel.org (Postfix) with ESMTPS id F1DA260B16; Sat, 22 Oct 2022 07:38:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 149A2C433C1; Sat, 22 Oct 2022 07:38:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1666424321; bh=ON2evzD/PvT7GNtyEBzFcCThvASigkcrWtkR+/CpAo0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=v/xdFGfpnOwkMBNw+QAFrqkPcKDXzeu8KfkGc9ZQcxGzz9LZjNeazv3JoNCF3hYBY xkwtjGCALXSEW5U953bczsN6ZjT4EzvRGZOTAG8iw6zdanpK0ISscP/hUFDJqFwMCi S0nISfpOEQw/aCGoeOFoZ+KhwOy5y+f9xfb1yDQU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Yogev Cohen , Sagi Grimberg , Christoph Hellwig Subject: [PATCH 5.19 062/717] nvme-multipath: fix possible hang in live ns resize with ANA access Date: Sat, 22 Oct 2022 09:19:01 +0200 Message-Id: <20221022072426.061018181@linuxfoundation.org> X-Mailer: git-send-email 2.38.1 In-Reply-To: <20221022072415.034382448@linuxfoundation.org> References: <20221022072415.034382448@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 X-Spam-Status: No, score=-7.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham 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 X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747376506528359828?= X-GMAIL-MSGID: =?utf-8?q?1747376506528359828?= From: Sagi Grimberg commit 72e3b8883a36e80ebfa41015c7b6926ce31ace05 upstream. When we revalidate paths as part of ns size change (as of commit e7d65803e2bb), it is possible that during the path revalidation, the only paths that is IO capable (i.e. optimized/non-optimized) are the ones that ns resize was not yet informed to the host, which will cause inflight requests to be requeued (as we have available paths but none are IO capable). These requests on the requeue list are waiting for someone to resubmit them at some point. The IO capable paths will eventually notify the ns resize change to the host, but there is nothing that will kick the requeue list to resubmit the queued requests. Fix this by always kicking the requeue list, and if no IO capable path exists, these requests will be queued again. A typical log that indicates that IOs are requeued: --- nvme nvme1: creating 4 I/O queues. nvme nvme1: new ctrl: "testnqn1" nvme nvme2: creating 4 I/O queues. nvme nvme2: mapped 4/0/0 default/read/poll queues. nvme nvme2: new ctrl: NQN "testnqn1", addr 127.0.0.1:8009 nvme nvme1: rescanning namespaces. nvme1n1: detected capacity change from 2097152 to 4194304 block nvme1n1: no usable path - requeuing I/O block nvme1n1: no usable path - requeuing I/O block nvme1n1: no usable path - requeuing I/O block nvme1n1: no usable path - requeuing I/O block nvme1n1: no usable path - requeuing I/O block nvme1n1: no usable path - requeuing I/O block nvme1n1: no usable path - requeuing I/O block nvme1n1: no usable path - requeuing I/O block nvme1n1: no usable path - requeuing I/O block nvme1n1: no usable path - requeuing I/O nvme nvme2: rescanning namespaces. -- Reported-by: Yogev Cohen Fixes: e7d65803e2bb ("nvme-multipath: revalidate paths during rescan") Signed-off-by: Sagi Grimberg Cc: # v5.15+ Signed-off-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman --- drivers/nvme/host/multipath.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/nvme/host/multipath.c +++ b/drivers/nvme/host/multipath.c @@ -182,6 +182,7 @@ void nvme_mpath_revalidate_paths(struct for_each_node(node) rcu_assign_pointer(head->current_path[node], NULL); + kblockd_schedule_work(&head->requeue_work); } static bool nvme_path_is_disabled(struct nvme_ns *ns)