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 79BF3109C058 for ; Wed, 25 Mar 2026 19:03:52 +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-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=u4D9rC4+pGzjafwbxb1h5D8Unvhc7nlBkwxheY/yhKY=; b=eieAGGQ2UOLYcLSzdXo015rI2C 65rMoyrV/LKjCQoDSTDbiMLWpWH7wrPDdFR2LtgCt+BbE5N98lN/gILTnRRXCFgvcDqQ4lYtRc9sB UXfQVtDzPFtPs44qgv1U7pyM+uY5XBznWInSlRydb4GhcRhzWeV9xUkzcrsQNy2Un+fuh0bNYIpr6 AZYkqx69qjX+n0ASHMj4R2HyfxiBryvSouTtVcQ45il9JDPfC/DP53SS8cMkSsWxwC52aznOzPEmT 7l0Em5aE9Yrwmcx7FzeuSc3JLUe+Wvmgmtvilj9SDJxXVbRKqywO/AXNoulCht9BE5yAjAnZWB+/L e08I2Fig==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1w5TW7-0000000482r-1rbp; Wed, 25 Mar 2026 19:03:47 +0000 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1w5TW5-0000000482P-19BU; Wed, 25 Mar 2026 19:03:46 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 9B4754410D; Wed, 25 Mar 2026 19:03:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B6E80C4CEF7; Wed, 25 Mar 2026 19:03:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774465424; bh=DgQ3qaC2Lz7JXjgQE5MdN4pJqP27wdH8+jfM7VtghJw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=lFshch7zun/xteEkRaHuQ15A2RKwzQsU7TqxpJBs5M90rWZQZcaLJJVyI28Gk2hNZ gH6rvoYJlLK+ceyM2pvvSlsxv4/kQzMWRL0SqdkLRbxGTQrYkTt4F4n4jK6reDeuqx VYpoK6ZZNbD2Ts4JayS4UEQBD/mH4h7VFnYd4+aSI0NpIT3i793XrHRbf60jawrNDO YdUslpWDAJ7NCczS+u8iPLc5tUmtU69RG8pbam3mw55apHbClnX+CgYtIvMXyM4TiM Dz29XwzIH1TMSASf55aoQ58pOqkq4xR9vzHTqgRLYem6eVZyEgnS4sIYvhNS0KgcBB +udo9tjMHmUUA== Date: Wed, 25 Mar 2026 13:03:42 -0600 From: Keith Busch To: Justin Tee Cc: hmi.jeon@samsung.com, "axboe@kernel.dk" , "sven@kernel.org" , "j@jannau.net" , "neal@gompa.dev" , "hch@lst.de" , "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" Subject: Re: [PATCH v3] nvme: Add nvme_setup_cmd to host_path_error Message-ID: References: <20260320052101epcms2p42ae135da60b36685e9b7fca6849b57a6@epcms2p4> <945a3e98-ee75-453c-ae80-f3c9e3e57e58@gmail.com> <20260325063333epcms2p60954532c1b65a1665bad6dcdcfd7d62c@epcms2p6> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260325_120345_328872_5B51A304 X-CRM114-Status: GOOD ( 14.96 ) 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 Wed, Mar 25, 2026 at 11:37:44AM -0700, Justin Tee wrote: > > - After > > nvme_setup_cmd: \ > > nvme0: qid=0, cmdid=32777, nsid=0, flags=0x0, meta=0x0, \ > > cmd=(nvme_admin_identify cns=1, ctrlid=0) > > nvme_complete_rq: \ > > nvme0: qid=0, cmdid=32777, res=0x0, retries=0, flags=0x2, status=0x370 > > > diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c > > index 766e9cc4ffca..378d28b2c971 100644 > > --- a/drivers/nvme/host/core.c > > +++ b/drivers/nvme/host/core.c > > @@ -512,6 +512,7 @@ EXPORT_SYMBOL_GPL(nvme_complete_batch_req); > > blk_status_t nvme_host_path_error(struct request *req) > > { > > nvme_req(req)->status = NVME_SC_HOST_PATH_ERROR; > > + nvme_setup_cmd(req->q->queuedata, req); > > blk_mq_set_request_complete(req); > > nvme_complete_rq(req); > > return BLK_STS_OK; > > Since trace_nvme_complete_rq is printing only cmdid to help identify > the command, why not define a new TRACE_EVENT(nvme_host_path_error, > ...) in trace.h instead? Why are we even tracing the completion? I agree the completion without a submission is confusing, but why don't we just skip tracing the completion in this condition? The idea for these trace events was to match up commands dispatched to hardware with the hardware's posted response, so I'm not sure what value we get by synthesizing both sides of the events.