All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
To: Mohamed Khalfella <mkhalfella@purestorage.com>
Cc: linux-block@vger.kernel.org, Keith Busch <kbusch@kernel.org>,
	 Jens Axboe <axboe@kernel.dk>, Christoph Hellwig <hch@lst.de>,
	Sagi Grimberg <sagi@grimberg.me>,  Hannes Reinecke <hare@suse.de>,
	John Meneghini <jmeneghi@redhat.com>,
	 Jesse Taube <jtaubepe@redhat.com>,
	Randy Jennings <randyj@purestorage.com>,
	 Dhaval Giani <dgiani@purestorage.com>
Subject: Re: [PATCH blktests] nvme/071: test CCR and CQT recovery on a multipath fabrics namespace
Date: Fri, 25 Sep 2026 12:08:12 +0900	[thread overview]
Message-ID: <arXkH22uhHHdnaq3@shinmob> (raw)
In-Reply-To: <20260921205951.3023714-1-mkhalfella@purestorage.com>

On Sep 21, 2026 / 14:59, Mohamed Khalfella wrote:
> nvme/070 demonstrated the ABA ghost write window. The kernel closes it
> by fencing a controller before retrying timed-out writes on another
> path, but nvme/070 does not functionally exercise CCR or CQT
> themselves.
> 
> Add a functional test that drives both cross-controller reset (CCR)
> and command quiesce time (CQT) recovery. The setup is the same as
> nvme/070: a ublk loop device backs an nvmet namespace that is exported
> through two ports, the host connects to both paths, and io_timeout on
> the subsystem drops to 2 seconds. In addition, the target subsystem's
> CQT is set to 30 seconds, since it is disabled by default.
> 
> The first scenario holds one write in the backstore for 4 seconds. The
> host times the write out, starts fencing, and the CCR issued on the
> other path completes within its budget. The second scenario holds a
> write for 10 seconds, longer than CCR can wait, so the host gives up
> on CCR and switches to time-based recovery, waiting out the remaining
> CQT window before releasing the retry.
> 
> Each scenario runs nvme-ghost-write-detector while recovery is in flight
> to check that no stale data surfaces, and confirms the recovery took the
> expected route by watching dmesg after a marker written to /dev/kmsg.
> 
> The test requires nvme_core.multipath=Y and is limited to tcp, rdma
> and fc, the transports that implement controller fencing.
> 
> Signed-off-by: Mohamed Khalfella <mkhalfella@purestorage.com>

Thanks. Overall, this patch looks valuable, and I did not see problems.

As I commented on the dependent series [*], this patch also depends on the
miniublk change. This approach looks useful for this kind of precise test
condition control, but the two points I noted will need consideration.

dmesg_mark() and dmesg_since_mark() can be useful for other future test
cases, and may worth adding to common/rc. Also, it can be refactored with
_dmesg_since_test_start(). Said that, I think current patch is fine and
we can do that refactoring work later.

[*] https://lore.kernel.org/linux-block/arOFG9-sM_GrrbQf@shinmob/

      reply	other threads:[~2026-09-25  3:08 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-21 20:59 [PATCH blktests] nvme/071: test CCR and CQT recovery on a multipath fabrics namespace Mohamed Khalfella
2026-09-25  3:08 ` Shin'ichiro Kawasaki [this message]

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=arXkH22uhHHdnaq3@shinmob \
    --to=shinichiro.kawasaki@wdc.com \
    --cc=axboe@kernel.dk \
    --cc=dgiani@purestorage.com \
    --cc=hare@suse.de \
    --cc=hch@lst.de \
    --cc=jmeneghi@redhat.com \
    --cc=jtaubepe@redhat.com \
    --cc=kbusch@kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=mkhalfella@purestorage.com \
    --cc=randyj@purestorage.com \
    --cc=sagi@grimberg.me \
    /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.