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 8235B2DC355 for ; Wed, 11 Feb 2026 12:27:53 +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=1770812873; cv=none; b=eUbAO3JadTTxrKxWql4NeIghj3ERtCZpj0vFnkOfEa1hhjbGDyjMz5HzYGZVdm6DxsuIE1iiuy+w3cwYTSSA5Xx8H27L6UO1/4fqCLlY9cxBAKt9fc2JaHig5P55md7W7cs0M959LS+bBZgPINwbd1oM0PNAWwLLNYEC1jkhjPU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770812873; c=relaxed/simple; bh=w7GQWxpWfMH/EJ1S8C6A9RnWp8YSIVRkPxwYTRA0GbE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=k+fN8G8nXIF+qs1MSNwa32odXaEFpq3o4wDidcxqyQaMZJlw3btzu83kPMtS+UIa8BT8ZnKfU4WiF7HR6aBdA4LIK+dBkDXLPrVjWaNzRR8W5lcVKGQNXZXlJtnSgHDBqy3BUD272ABHupNywrgrwzutVazWZP0KvUoGOWp0z6U= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=AGkjKUmh; 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="AGkjKUmh" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 89052C4CEF7; Wed, 11 Feb 2026 12:27:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1770812873; bh=w7GQWxpWfMH/EJ1S8C6A9RnWp8YSIVRkPxwYTRA0GbE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=AGkjKUmh6mQvczwkjjTWqa5kFIIyqjB1SHTUVJeOyVRlpGvTeEbZEckVD290AgZIy zJttEbdwgjZvEOKrjRm1xCsspJrmKo167EQ5lkdWVuGAkgXkBJkmSNyH7LI214CwLP kT/L8O0F74rHrmqT/+Nfnb5RMuVnwAeW4cVDFJWftuONpttrz/U8/cM+QENwCysx1g bopr184QGPB+JzvJyfufTQ8IqACz/eKb4QU1bjVKBIYD3hg9I98kvM6SqKl5ng0TUx r/PyusynBtRC72q2tpS6L2SqHAfPn84FDDH/Fs0UzCgqCDJUl3Rw14Kv+ehAlUG4JL ud7X4REhThtBg== Date: Wed, 11 Feb 2026 05:27:50 -0700 From: Keith Busch To: Junnan Zhang Cc: axboe@kernel.dk, hch@lst.de, linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org, liuyx92@chinatelecom.cn, sagi@grimberg.me, sunshx@chinatelecom.cn, yuanql9@chinatelecom.cn, zhangjn11@chinatelecom.cn, zhangzl68@chinatelecom.cn Subject: Re: [PATCH] nvme-pci: fix potential I/O hang when CQ is full Message-ID: References: <20260209121020.119853-1-zhangjn_dev@163.com> <20260211094744.32366-1-zhangjn_dev@163.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260211094744.32366-1-zhangjn_dev@163.com> On Wed, Feb 11, 2026 at 05:47:44PM +0800, Junnan Zhang wrote: > On Tue, 10 Feb 2026 16:57:12 +0100, Christoph Hellwig wrote: > > > We can't update the CQ head before consuming the CQEs, otherwise > > the device can reuse them. And devices must not discard completions > > when there is no completion queue entry, nvme does allow SQs and CQs > > to be smaller than the number of outstanding commands. > > Updating the CQ head before consuming the CQE would not cause the device to > reuse these entries, as new commands can only be submitted by the driver after > the CQE is consumed. Therefore, the device does not have the opportunity > to reuse these entries. That's just an artifact of how this host implementation constrains its tag space. It's not a reflection of how the NVMe protocol fundamentally works. A full queue is not an error. It's a spec defined condition that the submitter just has to deal with. The protocol was specifically made to allow scenarios for dispatching more outstanding commands than the queues can hold. Your controller is broken.