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 D5C3C144304; Thu, 13 Jun 2024 11:42:56 +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=1718278976; cv=none; b=LXovumkuVwL/cSUBHrZCLsl4EwtgshaWEtQu/WlQc13xLkcad66pSdeL+/L7FpzLIXKwJq7FjbRVqHHEgVfshOXDPbtos9WG/EcAXQDC9OIqAFybUy9VZ1hh5XXVPn79e1pQ+QwR0zqa2GsReqDZepGiMG3OcvdHaq/sC5py85s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718278976; c=relaxed/simple; bh=lSJOZl1nEIyYjtJJsDEzdWPjNTC8cg3C0E36R1XF4Oc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=AXq8O4VOBoegqy+Aci+d4uWJ0YJu4eNRHaCLPhdDKDejOdMXzRx0sdl0ZHMUwVF4rPeh/Mv4eih9Uud25s9F4eD6BzRD6lMwxIjK7v3SYDGFF09UyM+1ybWAE0PQFlfuLBQfY7dfe5G151FqS0CQ0eivJK3+I/GfKuorAg5vksA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=i6oAraBX; 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="i6oAraBX" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E8C87C2BBFC; Thu, 13 Jun 2024 11:42:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1718278976; bh=lSJOZl1nEIyYjtJJsDEzdWPjNTC8cg3C0E36R1XF4Oc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=i6oAraBX+qYYgr1NnC9kP+8VIN2CikeBLord4uCgNZMJd1s/mX54AspKhE6bEGxfQ 6ZyWbExcsJOVJnH/z7bSKjWwIBbLrEDS+l/qM6uRwzSRWymULxMClznsF8uy1+Y8dA WKSf058k70A8hT0GkVReSm8tfncnyyGmknuWqv0k= 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 4.19 133/213] nvmet: fix ns enable/disable possible hang Date: Thu, 13 Jun 2024 13:33:01 +0200 Message-ID: <20240613113233.127815638@linuxfoundation.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20240613113227.969123070@linuxfoundation.org> References: <20240613113227.969123070@linuxfoundation.org> User-Agent: quilt/0.67 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 4.19-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 b37a8e3e3f800..921efb20f6d7b 100644 --- a/drivers/nvme/target/configfs.c +++ b/drivers/nvme/target/configfs.c @@ -464,10 +464,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