From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B3BC619AA56; Mon, 17 Jun 2024 13:22:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718630523; cv=none; b=n8iALlF24AntiBKU2m19UVkn9Sl2xUDtyHUVgN/KFryr4tfmNz9bKVhu1C6PXR6/uYS8S3arP51nTzVBOlwWYcyAc6Udsg11YdUVLltBXEYC17JJAQiyx+JDG9L16l2bDqwXRHxvC+473piwNBa3bekcCTaHKgjnlxk5PA1fsR0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718630523; c=relaxed/simple; bh=YNwSeyUWooZMAG25GZh73ttHKehOSMr/3V06jP+H6BM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=DntJo+QVHdEkGK0kvhBMDrphEl/8vginQo68lTI5PlaUXFAIm2MedV4p85I51J2NZTDluh/tPwt5JcM9MF7/9vjsiJzTJZr/rhpxqxhtDpjb+/wQC0Lujx5iAmZijFSTT72uiiYTy4KDMeL9kTXk5taBYWZY9FDEUAnj5KqIbiA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=sBF1l/oN; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="sBF1l/oN" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4BD6CC4AF1C; Mon, 17 Jun 2024 13:22:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1718630523; bh=YNwSeyUWooZMAG25GZh73ttHKehOSMr/3V06jP+H6BM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=sBF1l/oNC2VCvyhAk7teW2JRa714KNbC4zIrudYwiybCpS/JL6kiPW/DyVnTkO63b I+KxtfKNrjKZ2WJjGEUXQBf7IkHdWIL7Cjw1HLGJma8dIEmIEOgr35tOYRvy076uUK pIwJsOYX0ORbZ8K8VgR2atBqwsR4gQxJGPCnKiPVzhwo4tlxnvOl1v26nt/Hz7zzYQ 0KvCH4aGOKIWz90pSxPQd2/88rgFyNEsvvpQ4O4k9s/qdlUigz80lmd5R6gd37O18c /RkNyAj/cxT0Iz4wIHz4m9Y/nAEDKwRs6Jh1lqjEgkcO0xcfFpuGWzLb4UMlLerJAA 5FBLNmUQd3SVA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Chunguang Xu , Sagi Grimberg , Chaitanya Kulkarni , Christoph Hellwig , Keith Busch , Sasha Levin , linux-nvme@lists.infradead.org Subject: [PATCH AUTOSEL 6.9 30/44] nvme-fabrics: use reserved tag for reg read/write command Date: Mon, 17 Jun 2024 09:19:43 -0400 Message-ID: <20240617132046.2587008-30-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240617132046.2587008-1-sashal@kernel.org> References: <20240617132046.2587008-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.9.5 Content-Transfer-Encoding: 8bit From: Chunguang Xu [ Upstream commit 7dc3bfcb4c9cc58970fff6aaa48172cb224d85aa ] In some scenarios, if too many commands are issued by nvme command in the same time by user tasks, this may exhaust all tags of admin_q. If a reset (nvme reset or IO timeout) occurs before these commands finish, reconnect routine may fail to update nvme regs due to insufficient tags, which will cause kernel hang forever. In order to workaround this issue, maybe we can let reg_read32()/reg_read64()/reg_write32() use reserved tags. This maybe safe for nvmf: 1. For the disable ctrl path, we will not issue connect command 2. For the enable ctrl / fw activate path, since connect and reg_xx() are called serially. So the reserved tags may still be enough while reg_xx() use reserved tags. Signed-off-by: Chunguang Xu Reviewed-by: Sagi Grimberg Reviewed-by: Chaitanya Kulkarni Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Signed-off-by: Sasha Levin --- drivers/nvme/host/fabrics.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/nvme/host/fabrics.c b/drivers/nvme/host/fabrics.c index 1f0ea1f32d22f..f6416f8553f03 100644 --- a/drivers/nvme/host/fabrics.c +++ b/drivers/nvme/host/fabrics.c @@ -180,7 +180,7 @@ int nvmf_reg_read32(struct nvme_ctrl *ctrl, u32 off, u32 *val) cmd.prop_get.offset = cpu_to_le32(off); ret = __nvme_submit_sync_cmd(ctrl->fabrics_q, &cmd, &res, NULL, 0, - NVME_QID_ANY, 0); + NVME_QID_ANY, NVME_SUBMIT_RESERVED); if (ret >= 0) *val = le64_to_cpu(res.u64); @@ -226,7 +226,7 @@ int nvmf_reg_read64(struct nvme_ctrl *ctrl, u32 off, u64 *val) cmd.prop_get.offset = cpu_to_le32(off); ret = __nvme_submit_sync_cmd(ctrl->fabrics_q, &cmd, &res, NULL, 0, - NVME_QID_ANY, 0); + NVME_QID_ANY, NVME_SUBMIT_RESERVED); if (ret >= 0) *val = le64_to_cpu(res.u64); @@ -271,7 +271,7 @@ int nvmf_reg_write32(struct nvme_ctrl *ctrl, u32 off, u32 val) cmd.prop_set.value = cpu_to_le64(val); ret = __nvme_submit_sync_cmd(ctrl->fabrics_q, &cmd, NULL, NULL, 0, - NVME_QID_ANY, 0); + NVME_QID_ANY, NVME_SUBMIT_RESERVED); if (unlikely(ret)) dev_err(ctrl->device, "Property Set error: %d, offset %#x\n", -- 2.43.0