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 EDE56384; Thu, 13 Jun 2024 12:42:13 +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=1718282534; cv=none; b=sc1v0zZSB+gLBg7uq0bCXdfHLyoZi2OjQcUAVKDvlcZTSvmesOP9yEtp9z2X8f0KxnBC5PfDRKTUb5AmxM0FNFip1kSM6k/7hZV72OK2STF1Q/beG+xQ3pWNKYiOiOS3es+hSwcjcF6eBtL6Q+8IrQMvEgluGKxjvSJXATUiISc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718282534; c=relaxed/simple; bh=M+yNDnQPsdoS2kdilI5yT3OFDzsLtRc3SuEO9qejQrY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=sRMDZM2tmg+QCz+XjI9X4qcQj/3JUdjooZPyvBa/bReGrhxt4p8aOacrbL2lwbyC6hHmXS+kqYfPEXlXwdOcioDOddZyPdl/9nbCfPD2T1R3MwUlcbdBXc4PzNN8mkQQqwaUyJbxgOgqw9vG/Jw5GhkaxH/Ch4vd4jfAS4IuzkU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=a+wje3Ti; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="a+wje3Ti" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2DE51C2BBFC; Thu, 13 Jun 2024 12:42:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1718282533; bh=M+yNDnQPsdoS2kdilI5yT3OFDzsLtRc3SuEO9qejQrY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=a+wje3TiTS1sTCwiFVdUV0I3C6Gs/GjfdnqnOMcXAD87rGICdYYSGHK0bgDqViH/P q/wyy890PfvAdcA/jmPC6Dw2nghiojBdde01T8Epd516wIc3v5EQXxQ/OElxnc1YJ9 xgyn7qN9OYxdTRFAYKzDEpugBInXm36AHCyyyeqM= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Sagi Grimberg , Christoph Hellwig , Chaitanya Kulkarni , Keith Busch , Sasha Levin Subject: [PATCH 5.15 309/402] nvmet: fix ns enable/disable possible hang Date: Thu, 13 Jun 2024 13:34:26 +0200 Message-ID: <20240613113314.194445733@linuxfoundation.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20240613113302.116811394@linuxfoundation.org> References: <20240613113302.116811394@linuxfoundation.org> User-Agent: quilt/0.67 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 5.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Sagi Grimberg [ Upstream commit f97914e35fd98b2b18fb8a092e0a0799f73afdfe ] When disabling an nvmet namespace, there is a period where the subsys->lock is released, as the ns disable waits for backend IO to complete, and the ns percpu ref to be properly killed. The original intent was to avoid taking the subsystem lock for a prolong period as other processes may need to acquire it (for example new incoming connections). However, it opens up a window where another process may come in and enable the ns, (re)intiailizing the ns percpu_ref, causing the disable sequence to hang. Solve this by taking the global nvmet_config_sem over the entire configfs enable/disable sequence. Fixes: a07b4970f464 ("nvmet: add a generic NVMe target") Signed-off-by: Sagi Grimberg Reviewed-by: Christoph Hellwig Reviewed-by: Chaitanya Kulkarni Signed-off-by: Keith Busch Signed-off-by: Sasha Levin --- drivers/nvme/target/configfs.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/nvme/target/configfs.c b/drivers/nvme/target/configfs.c index 5bdc3ba51f7ef..a3d3a1bfd292d 100644 --- a/drivers/nvme/target/configfs.c +++ b/drivers/nvme/target/configfs.c @@ -530,10 +530,18 @@ static ssize_t nvmet_ns_enable_store(struct config_item *item, if (strtobool(page, &enable)) return -EINVAL; + /* + * take a global nvmet_config_sem because the disable routine has a + * window where it releases the subsys-lock, giving a chance to + * a parallel enable to concurrently execute causing the disable to + * have a misaccounting of the ns percpu_ref. + */ + down_write(&nvmet_config_sem); if (enable) ret = nvmet_ns_enable(ns); else nvmet_ns_disable(ns); + up_write(&nvmet_config_sem); return ret ? ret : count; } -- 2.43.0