From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8D26BC3A5A6 for ; Sun, 22 Sep 2019 19:32:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6124F206B6 for ; Sun, 22 Sep 2019 19:32:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1569180779; bh=4Ewei6nFu8UH+9+UcQT2aqOUudzBkl/2gZljAtwog70=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=GWYODptK0l+Q7/fOWtt/8nbv7upON6lCvXBRaxKvr8lkQTnwWIvJxSDPG4nbeU6T2 //LOxR9iATh68OA92RZMRubX2CFiBhd25HJGYygrzY6PWHf8Q3jA3EmcVkF+tooBzY IdbNHWhhFXi3gUmi1Xf3KnB8qsMEv9aTjVfEBIoI= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390155AbfIVTcv (ORCPT ); Sun, 22 Sep 2019 15:32:51 -0400 Received: from mail.kernel.org ([198.145.29.99]:44514 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388816AbfIVSrz (ORCPT ); Sun, 22 Sep 2019 14:47:55 -0400 Received: from sasha-vm.mshome.net (c-73-47-72-35.hsd1.nh.comcast.net [73.47.72.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id BB1D92186A; Sun, 22 Sep 2019 18:47:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1569178074; bh=4Ewei6nFu8UH+9+UcQT2aqOUudzBkl/2gZljAtwog70=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hrEz7EhNwM2t3IgO/6YPhoalLXki/n/6YMwxsz8gWXMtHiixwHghLi23inWyR3igb PQdpEfV9mcml/2JWQoKoJb53+2klDoIwukR06wtjWuN+CuKk/s65kdGe05Z5N822hr OD4N4FNLrlfvt12LBz+PLTT4U8SzAtzJy79aXJaA= From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Anton Eidelman , James Smart , Hannes Reinecke , Christoph Hellwig , Sagi Grimberg , Sasha Levin , linux-nvme@lists.infradead.org Subject: [PATCH AUTOSEL 5.3 146/203] nvme-multipath: fix ana log nsid lookup when nsid is not found Date: Sun, 22 Sep 2019 14:42:52 -0400 Message-Id: <20190922184350.30563-146-sashal@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190922184350.30563-1-sashal@kernel.org> References: <20190922184350.30563-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Anton Eidelman [ Upstream commit e01f91dff91c7b16a6e3faf2565017d497a73f83 ] ANA log parsing invokes nvme_update_ana_state() per ANA group desc. This updates the state of namespaces with nsids in desc->nsids[]. Both ctrl->namespaces list and desc->nsids[] array are sorted by nsid. Hence nvme_update_ana_state() performs a single walk over ctrl->namespaces: - if current namespace matches the current desc->nsids[n], this namespace is updated, and n is incremented. - the process stops when it encounters the end of either ctrl->namespaces end or desc->nsids[] In case desc->nsids[n] does not match any of ctrl->namespaces, the remaining nsids following desc->nsids[n] will not be updated. Such situation was considered abnormal and generated WARN_ON_ONCE. However ANA log MAY contain nsids not (yet) found in ctrl->namespaces. For example, lets consider the following scenario: - nvme0 exposes namespaces with nsids = [2, 3] to the host - a new namespace nsid = 1 is added dynamically - also, a ANA topology change is triggered - NS_CHANGED aen is generated and triggers scan_work - before scan_work discovers nsid=1 and creates a namespace, a NOTICE_ANA aen was issues and ana_work receives ANA log with nsids=[1, 2, 3] Result: ana_work fails to update ANA state on existing namespaces [2, 3] Solution: Change the way nvme_update_ana_state() namespace list walk checks the current namespace against desc->nsids[n] as follows: a) ns->head->ns_id < desc->nsids[n]: keep walking ctrl->namespaces. b) ns->head->ns_id == desc->nsids[n]: match, update the namespace c) ns->head->ns_id >= desc->nsids[n]: skip to desc->nsids[n+1] This enables correct operation in the scenario described above. This also allows ANA log to contain nsids currently invisible to the host, i.e. inactive nsids. Signed-off-by: Anton Eidelman Reviewed-by: James Smart Reviewed-by: Hannes Reinecke Reviewed-by: Christoph Hellwig Signed-off-by: Sagi Grimberg Signed-off-by: Sasha Levin --- drivers/nvme/host/multipath.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/nvme/host/multipath.c b/drivers/nvme/host/multipath.c index af831d3d15d07..30de7efef0035 100644 --- a/drivers/nvme/host/multipath.c +++ b/drivers/nvme/host/multipath.c @@ -509,14 +509,16 @@ static int nvme_update_ana_state(struct nvme_ctrl *ctrl, down_write(&ctrl->namespaces_rwsem); list_for_each_entry(ns, &ctrl->namespaces, list) { - if (ns->head->ns_id != le32_to_cpu(desc->nsids[n])) + unsigned nsid = le32_to_cpu(desc->nsids[n]); + + if (ns->head->ns_id < nsid) continue; - nvme_update_ns_ana_state(desc, ns); + if (ns->head->ns_id == nsid) + nvme_update_ns_ana_state(desc, ns); if (++n == nr_nsids) break; } up_write(&ctrl->namespaces_rwsem); - WARN_ON_ONCE(n < nr_nsids); return 0; } -- 2.20.1