From: Christoph Hellwig <hch@lst.de>
To: Andrea Parri <parri.andrea@gmail.com>
Cc: "Christoph Hellwig" <hch@lst.de>,
"Sagi Grimberg" <sagi@grimberg.me>,
"Chaitanya Kulkarni" <kch@nvidia.com>,
"Damien Le Moal" <dlemoal@kernel.org>,
"Keith Busch" <kbusch@kernel.org>,
"Manivannan Sadhasivam" <mani@kernel.org>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
"Niklas Cassel" <cassel@kernel.org>,
linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH 4/5] nvmet: pci-epf: report transport errors in command completions
Date: Tue, 13 Oct 2026 16:27:36 +0200 [thread overview]
Message-ID: <20261013142736.GE14759@lst.de> (raw)
In-Reply-To: <20261012141239.156408-5-parri.andrea@gmail.com>
I think this looks good. Damien/Niklas, can you test this on hardware?
On Mon, Oct 12, 2026 at 04:12:31PM +0200, Andrea Parri wrote:
> When the PCI endpoint target fails a command itself, the host receives a
> successful completion. This happens for a data length above MDTS,
> malformed PRPs or SGLs, a buffer allocation failure, an SQ that is not
> live, and a failed DMA of the command data. A write whose data cannot be
> fetched from the host is thus reported as written, though nothing was
> executed.
>
> Each of these paths sets iod->status and calls
> nvmet_pci_epf_complete_iod(), which then reloads iod->status from
> iod->cqe.status. The nvmet core only fills that field when it completes
> the request, which these paths never do, so it is still zero and
> nvmet_pci_epf_cq_work() posts a success status to the host.
>
> Drop the reload. Every path already sets iod->status before completion:
> nvmet_pci_epf_queue_response() copies it from the request's CQE, and
> the transport error paths set it themselves.
>
> Found by code inspection. Build-tested only (x86_64, W=1): no PCI
> endpoint hardware was available to run it.
>
> Fixes: 0faa0fe6f90e ("nvmet: New NVMe PCI endpoint function target driver")
> Cc: stable@vger.kernel.org
> Assisted-by: LLM
> Signed-off-by: Andrea Parri <parri.andrea@gmail.com>
> ---
> drivers/nvme/target/pci-epf.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/nvme/target/pci-epf.c b/drivers/nvme/target/pci-epf.c
> index c683450df4227..4c5fff232fb99 100644
> --- a/drivers/nvme/target/pci-epf.c
> +++ b/drivers/nvme/target/pci-epf.c
> @@ -1152,7 +1152,6 @@ static void nvmet_pci_epf_complete_iod(struct nvmet_pci_epf_iod *iod)
> unsigned long flags;
>
> /* Print an error message for failed commands, except AENs. */
> - iod->status = le16_to_cpu(iod->cqe.status) >> 1;
> if (iod->status && iod->cmd.common.opcode != nvme_admin_async_event)
> dev_err(iod->ctrl->dev,
> "CQ[%d]: Command %s (0x%x) status 0x%0x\n",
> --
> 2.53.0
---end quoted text---
next prev parent reply other threads:[~2026-10-13 14:27 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-12 14:12 [PATCH 0/5] nvmet: fix stale data exposure and ZNS validation Andrea Parri
2026-10-12 14:12 ` [PATCH 1/5] nvmet-fc: only send read data for successful commands Andrea Parri
2026-10-12 14:12 ` [PATCH 2/5] nvmet: zns: don't leak stale memory in zone management receive Andrea Parri
2026-10-13 14:25 ` Christoph Hellwig
2026-10-13 15:47 ` Keith Busch
2026-10-12 14:12 ` [PATCH 3/5] nvmet: zns: reject a NUMD whose byte count wraps Andrea Parri
2026-10-13 14:26 ` Christoph Hellwig
2026-10-12 14:12 ` [PATCH 4/5] nvmet: pci-epf: report transport errors in command completions Andrea Parri
2026-10-13 14:27 ` Christoph Hellwig [this message]
2026-10-13 15:12 ` Damien Le Moal
2026-10-12 14:12 ` [PATCH 5/5] nvmet: pci-epf: require SGLs to match the command data length Andrea Parri
2026-10-13 14:28 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261013142736.GE14759@lst.de \
--to=hch@lst.de \
--cc=cassel@kernel.org \
--cc=dlemoal@kernel.org \
--cc=kbusch@kernel.org \
--cc=kch@nvidia.com \
--cc=kwilczynski@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=mani@kernel.org \
--cc=parri.andrea@gmail.com \
--cc=sagi@grimberg.me \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.