From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id EF09910A62F9 for ; Thu, 26 Mar 2026 14:31:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To: Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=cqAo4B4Zn6p/GYAnn/u81HTFZV5FsFBQHnaL2sPYiTY=; b=tgunrRZdGlFHhMaodqD/b+l/j6 yK+boWTUMvVhxzlxktPnizmgm9aRVSJvurQ890UfRuxhOGCDiwhbX9R4GMJqZdWddpAfSWIcJw00n mhxe2MBa56NosdGD5NO3AvKTxVr4eD9a4IhUzNjZpNoMUdbzkJWvdBvj0tIP2Y96I8+sMvPY53zL0 J4E9joI9Jel46nRGdSs0qcM6j7ttIFHBjtF9Ns9wlcDeWIhQjJv7Y69cv5Yn9ESdYMAJvxLMEqBDD +Wi40sxueeXTnhQTe/CBdK7Xnv5XSP5bMHO4ZpHtk+aLPhC3uUgy3zjuDwSPxf2wywTEJu05C/9PK GPNKPjzQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1w5lkD-00000005eSd-3IN3; Thu, 26 Mar 2026 14:31:33 +0000 Received: from verein.lst.de ([213.95.11.211]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1w5lkB-00000005eRS-1JDn; Thu, 26 Mar 2026 14:31:32 +0000 Received: by verein.lst.de (Postfix, from userid 2407) id 7013B68CFE; Thu, 26 Mar 2026 15:31:24 +0100 (CET) Date: Thu, 26 Mar 2026 15:31:24 +0100 From: "hch@lst.de" To: Keith Busch Cc: =?utf-8?B?7KCE66+87Iud?= , "hch@lst.de" , Justin Tee , "axboe@kernel.dk" , "sven@kernel.org" , "j@jannau.net" , "neal@gompa.dev" , "sagi@grimberg.me" , "justin.tee@broadcom.com" , "nareshgottumukkala83@gmail.com" , "paul.ely@broadcom.com" , James Smart , "kch@nvidia.com" , "linux-arm-kernel@lists.infradead.org" , "linux-nvme@lists.infradead.org" , "asahi@lists.linux.dev" , "linux-kernel@vger.kernel.org" , =?utf-8?B?7J207J2A7IiY?= , =?utf-8?B?7Lm47LCs?= Subject: Re: [PATCH v5] nvme: Skip trace complete_rq on host path error Message-ID: <20260326143124.GA17507@lst.de> References: <20260326061443.GA23850@lst.de> <20260320052101epcms2p42ae135da60b36685e9b7fca6849b57a6@epcms2p4> <945a3e98-ee75-453c-ae80-f3c9e3e57e58@gmail.com> <20260325063333epcms2p60954532c1b65a1665bad6dcdcfd7d62c@epcms2p6> <20260326014429epcms2p135ffd3c2b2fface6423d045e9614c262@epcms2p1> <20260326065152epcms2p51a18d3bbecb6eb6dc2ddba09651e5152@epcms2p5> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260326_073131_514380_00679F63 X-CRM114-Status: GOOD ( 17.44 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Mar 26, 2026 at 08:28:46AM -0600, Keith Busch wrote: > On Thu, Mar 26, 2026 at 03:51:52PM +0900, 전민식 wrote: > > { > > struct nvme_ctrl *ctrl = nvme_req(req)->ctrl; > > > > - trace_nvme_complete_rq(req); > > + /* > > + * The idea for these trace events was to match up commands > > + * dispatched to hardware with the hardware's posted response. > > + * So skip tracing for undispatched commands. > > + */ > > + if (nvme_req(req)->status != NVME_SC_HOST_PATH_ERROR) > > + trace_nvme_complete_rq(req); > > + > > Well, how do we know a controller doesnn't actually return that status > code? I was just suggesting to skip the trace for the condition we never > dispatched the command. An added bonus is we don't need a mostly > unnecessary 'if' check on every IO. The 7?h error values were added for host use. The description of the section in the spec suggests this, but isn't actually as clear as I would like it. I wonder if we need to verify that controller don't incorrectly return it, as that could cause some problems? Independent of that your patch below looks sane to me.