From: Keith Busch <kbusch@kernel.org>
To: Ye Bin <yebin@huaweicloud.com>
Cc: axboe@kernel.dk, hch@lst.de, sagi@grimberg.me,
linux-nvme@lists.infradead.org, yebin10@huawei.com
Subject: Re: [PATCH 2/2] nvme: avoid possible double completions for the same request
Date: Mon, 8 Jun 2026 09:17:23 -0600 [thread overview]
Message-ID: <aibdA7YtCt5OS1EQ@kbusch-mbp> (raw)
In-Reply-To: <20260608113425.3836619-3-yebin@huaweicloud.com>
On Mon, Jun 08, 2026 at 07:34:25PM +0800, Ye Bin wrote:
> To avoid the preceding problem, the NVME_REQ_COMPLETE flag is added by
> referring to the implementation of scsi commit f1342709d18a ("scsi: Do not
> rely on blk-mq for double completions").
That scsi commit was solving a different problem for a racing
interaction between the low level driver and the timeout handler and
error injection. It wasn't about protecting against misbehaving
hardware.
> static inline struct nvme_request *nvme_req(struct request *req)
> @@ -807,6 +808,8 @@ static inline bool nvme_try_complete_req(struct request *req, __le16 status,
> nvme_should_fail(req);
> if (unlikely(blk_should_fake_timeout(req->q)))
> return true;
> + if (unlikely(test_and_set_bit(NVME_REQ_COMPLETE, &rq->flags)))
> + return true;
I think you need to invert this flag from "COMPLETE" to "INFLIGHT",
because the default allocated state is that this flag is cleared, so
this check as you have it wouldn't catch a phantom completion to a
request the host never sent.
You also have this check after the driver updated its internal
generation counter for a bogus completion, so now our actual state could
be off from what's actually being prepared.
This previous proposal for a similar problem was probably more on the
right track:
https://lore.kernel.org/linux-nvme/20260522153034.2168862-1-coshi036@gmail.com/
However, I'm really skeptical controllers actually behave this way. You
wouldn't have a viable storage device if it was doing this.
next prev parent reply other threads:[~2026-06-08 15:17 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-08 11:34 [PATCH 0/2] avoid possible double completions for the same request Ye Bin
2026-06-08 11:34 ` [PATCH 1/2] nvme: operate nvme_request->flags with atomic api Ye Bin
2026-06-08 11:34 ` [PATCH 2/2] nvme: avoid possible double completions for the same request Ye Bin
2026-06-08 15:17 ` Keith Busch [this message]
2026-06-08 15:20 ` Jens Axboe
2026-06-09 8:56 ` yebin
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=aibdA7YtCt5OS1EQ@kbusch-mbp \
--to=kbusch@kernel.org \
--cc=axboe@kernel.dk \
--cc=hch@lst.de \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
--cc=yebin10@huawei.com \
--cc=yebin@huaweicloud.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox