From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 DEFBB430CE2 for ; Tue, 11 Aug 2026 17:07:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786468022; cv=none; b=aMrq25QIQPs268phaFkgaRsqiAt518GkPaaoO2HD1hgQ9TDvdUmtfm1f+GltsjAyDTiWolqYdCqUipivGJQbs+6UD/DnLK27YEMx1+oLXmeu0nGrNKZPrdxKzTUO9StDh7hkPy9cCMNaveGUELnn8cWU5a/HkIFDtZoBUyRmly8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786468022; c=relaxed/simple; bh=usxziSmeNzD+wLQKfQJnx9XJ5NCw7OuIsQP/gHpdvzs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=B9iVphmUODFQsw/XGqfFPlr0ZqGe0l0xsCBSjydrMakiDvY3CAwBzXqQsbLaftLn2Io0YQ9NxxJ2TuoZmsCzcBM9Aj7km1kTQD95cutoNNn4OWJcsheH8W2EMUaLcpR4erlZgKqEJ5iJrrVYW+YEqhy5R3k3aFqKnCvavs+eSTM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=gTb1Y+yR; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="gTb1Y+yR" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5D7E61F00A3D; Tue, 11 Aug 2026 17:07:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786468020; bh=E08UpFHu5hxN+1hMKTZjWNxPsM8o+k329eLQADLj7n8=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=gTb1Y+yRm4yxZejz1qKhXcxRERX6ulEq62BRGc5FlNYeItDtwXvhH6VXq9B8sKa/H zYtWJKIXLoFQjyPxlirwZX2dG3cx7Iz0+2aUvE5h4336QhJ4aMaPJinBTCyDBWzuEO CXYqhQCdxemlx3b5sPFtCwu7ODGVW8BaX3C8ci/z6tuog7PMBqLyknNzvjc/C0ccR9 YTZa+10zFVBN7q30xyiQN0ZADj39SkZskcqaWXM66L8jQrOOF52dIHY8Uok+2UF0Lk O8vJqEBdYBfZ31ZimZ4dcYVl4x5/kJGoQ+kIwpURkKsN0DVKSt08zKoJwJ+Haa2oW2 M0x4uXlgFr5VQ== Date: Tue, 11 Aug 2026 11:06:58 -0600 From: Keith Busch To: Chao Shi Cc: Jens Axboe , Christoph Hellwig , Sagi Grimberg , linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] nvme: ratelimit the completion-path messages driven by device data Message-ID: References: <20260810220258.1960208-1-coshi036@gmail.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: <20260810220258.1960208-1-coshi036@gmail.com> On Mon, Aug 10, 2026 at 06:02:58PM -0400, Chao Shi wrote: > nvme_find_rq() and nvme_handle_cqe() print an unratelimited message for > every completion queue entry whose command id does not resolve to an > in-flight request. Both are reached from the completion interrupt path > (nvme_irq() -> nvme_poll_cq() -> nvme_handle_cqe()) and the decision to > print is made entirely from device-supplied data, so a controller that > posts a stream of bogus command ids drives unbounded printk from hard > interrupt context. Yeah, if a controller is so badly malfunctioning that only garbage is getting posted to the completion queues, then we don't really get any more information by dumping every single instance compared to rate limiting it. So applied to nvme-7.3, but with a minor fix to an overly long line.