From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from arkamax.eu (128-116-240-228.dyn.eolo.it [128.116.240.228]) (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 0D2BC3D349E for ; Tue, 28 Apr 2026 07:21:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=128.116.240.228 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777360916; cv=none; b=OrQerxiUvzK9s4yH+wRy06vGuqGVBHlVK+ZbnSyD2kGdMk9J61PIgUBae5kChAbZqSadxKKGTzOAbA+oSPqjTRH8o+7skgUGdXL4pswOxKF7yCTYndHOAwlLZxsNH9xQEq7gmuLXPUxJ8XXcb6RiZgFyFRQ0yL286YF89lKnEp0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777360916; c=relaxed/simple; bh=1ew3CZ85CObnPWqt2eXmHjOM3htWfx8AwZ3dHVKYZ1s=; h=Mime-Version:Content-Type:Date:Message-Id:From:To:Cc:Subject: References:In-Reply-To; b=rr/ixKTrkm6ErPC0Lkp7KVyCN43L3Gl/8YIBr778nbRqSO25jot6HfHlm3k/E/ZmzAxfTWIszrwdSZozAt4OGQnotpHWgp6zL2U+ktzoEzczhjiSxeYrR1gwTd8qEOx72J46daV/x+nfcLDCFO3wPJh+b8Pa/skcy0CMrv6uENA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=arkamax.eu; spf=pass smtp.mailfrom=arkamax.eu; arc=none smtp.client-ip=128.116.240.228 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=arkamax.eu Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arkamax.eu Received: from localhost (128-116-240-228.dyn.eolo.it [128.116.240.228]) by arkamax.eu (OpenSMTPD) with ESMTPSA id 36abb07c (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Tue, 28 Apr 2026 09:15:10 +0200 (CEST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Tue, 28 Apr 2026 09:15:10 +0200 Message-Id: From: "Maurizio Lombardi" To: "Keith Busch" , "Chao Shi" Cc: , "Christoph Hellwig" , "Sagi Grimberg" , "Jens Axboe" , "Tatsuya Sasaki" , , "Sungwoo Kim" , "Dave Tian" , "Weidong Zhu" Subject: Re: [PATCH] nvme: reserve a keep-alive admin tag for all transports X-Mailer: aerc 0.21.0 References: <20260428022911.1288485-1-coshi036@gmail.com> In-Reply-To: On Tue Apr 28, 2026 at 8:47 AM CEST, Keith Busch wrote: > On Mon, Apr 27, 2026 at 10:29:11PM -0400, Chao Shi wrote: >> nvme_keep_alive_work() always allocates with BLK_MQ_REQ_RESERVED, but >> nvme_alloc_admin_tag_set() only sets reserved_tags for fabrics. Since >> commit b58da2d270db ("nvme: update keep alive interval when kato is >> modified"), userspace can start keep-alive on any transport via Set >> Features (KATO), after which the allocation trips WARN_ON_ONCE() in >> blk_mq_get_tag() and fails with -EWOULDBLOCK: >>=20 >> nvme nvme0: keep-alive failed: -11 >>=20 >> Reserve one admin tag for keep-alive on all transports. Fabrics keeps >> two, the second being for the connect command. > =20 >> Fixes: b58da2d270db ("nvme: update keep alive interval when kato is modi= fied") >>=20 >> Found by FuzzNvme(Syzkaller with FEMU fuzzing framework). >>=20 >> Acked-by: Sungwoo Kim >> Acked-by: Dave Tian >> Acked-by: Weidong Zhu >> Signed-off-by: Chao Shi >> --- >>=20 >> Reproducer (run as root on an unpatched kernel with a PCIe NVMe device): > > You have a PCI controller that doesn't return Invalid Field In Command > status to the KATO feature? That's weird, it's fabrics specific feature. Are you sure that it's fabrics-only? The spec 2.0a, at section 5.27.1.12 Keep Alive Timer (Feature Identifier 0Fh) says: "Keep Alive Timeout (KATO): =20 This field specifies the timeout value for the Keep Alive feature in milliseconds. [...] The default value for this field is 0h for NVMe transports that do not requ= ire use of the Keep Alive feature (e.g., NVMe over PCIe). For NVMe transports that require use of the= Keep Alive feature (e.g., RDMA and TCP), the default value for this field is 1D4C0h " To me, it sounds like for nvme-pci, keep alive isn't required, but could be activated. Maurizio