From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from verein.lst.de (verein.lst.de [213.95.11.211])
	(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 521D4385EDA
	for <linux-kernel@vger.kernel.org>; Tue, 10 Feb 2026 15:57:16 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.95.11.211
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1770739037; cv=none; b=nuB/zYXFI8ILAipAeJmnV4vQYnpHmgdG+hacxzv8FtE6ItAE2lq91JC+mBcJZETuP7+LN+jr7TeNQasx7qkJTAWHjUyt+YMwnjkfNFimAyNE9aZPIY+fQ0dH64jh4qwVnI8fq6TyVnizuZa2h6XjXvQdSrXJmnT5QX8SdMXpy38=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1770739037; c=relaxed/simple;
	bh=uy2Vj/0VhVWe0sNJKgXqRWvZSrVx0gkHAoiNGqnM56Q=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=b7liMbAE8tnhQkDV2JXLwk5MJvhQWBJ3ibNjVkzuAQrYq/Lo8PsZl0I2Z8d1W6zl9XhpfWIVRx6FSCvSD510rj4d2hs8qu2ejRcGFqZBnZu+cJKHzocXn1p3/3u3Glso+rI7fBSg072uK/ESYVPdgl/gQC8s76zseTD2GY/HfjE=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lst.de; spf=pass smtp.mailfrom=lst.de; arc=none smtp.client-ip=213.95.11.211
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lst.de
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=lst.de
Received: by verein.lst.de (Postfix, from userid 2407)
	id 1097168CFE; Tue, 10 Feb 2026 16:57:13 +0100 (CET)
Date: Tue, 10 Feb 2026 16:57:12 +0100
From: Christoph Hellwig <hch@lst.de>
To: Junnan Zhang <zhangjn_dev@163.com>
Cc: Keith Busch <kbusch@kernel.org>, Jens Axboe <axboe@kernel.dk>,
	Christoph Hellwig <hch@lst.de>, Sagi Grimberg <sagi@grimberg.me>,
	Shouxin Sun <sunshx@chinatelecom.cn>,
	Junnan Zhang <zhangjn11@chinatelecom.cn>,
	Qiliang Yuan <yuanql9@chinatelecom.cn>,
	Zhaolong Zhang <zhangzl68@chinatelecom.cn>,
	Yaxuan Liu <liuyx92@chinatelecom.cn>,
	linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] nvme-pci: fix potential I/O hang when CQ is full
Message-ID: <20260210155712.GA3653@lst.de>
References: <20260209121020.119853-1-zhangjn_dev@163.com>
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20260209121020.119853-1-zhangjn_dev@163.com>
User-Agent: Mutt/1.5.17 (2007-11-01)

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.