From: Andrea Parri <parri.andrea@gmail.com>
To: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Cc: Andrea Parri <parri.andrea@gmail.com>,
linux-block@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
Keith Busch <kbusch@kernel.org>, Sagi Grimberg <sagi@grimberg.me>,
Chaitanya Kulkarni <kch@nvidia.com>,
Daniel Wagner <dwagner@suse.de>,
linux-nvme@lists.infradead.org
Subject: Re: [PATCH blktests 2/4] nvme/071: test that nvmet sends no data for a failed read
Date: Tue, 20 Oct 2026 17:17:31 +0200 [thread overview]
Message-ID: <20261020151732.90412-1-parri.andrea@gmail.com> (raw)
In-Reply-To: <atdDDxISK3i_5uQX@shinmob>
On Tue, Oct 20, 2026 at 07:35:53PM +0900, Shin'ichiro Kawasaki wrote:
> > +# Issue an Identify with CNS $2 to controller $1 and print the NVMe status
> > +# and the number of changed bytes in the 4096-byte data buffer.
> > +_identify() {
>
> In most cases, the function names that start with underscore are used for
> helper functions in common scripts. This function is used only in this script
> file, I suggest a function name that does not start with underscore. How about
> issue_identify() ?
Sure, issue_identify() it is.
> Do we really need this dd part below? As far as I understand, the core part of
> this test case is Identify command part above.
No, we don't. It was meant as a control that the fc fix still sends
data for successful reads, but the successful Identify above already
checks that: it must overwrite the whole 4096-byte buffer. I'll drop
the read, and with it the file backing, which was there only because
the read failed over the loop transport with the default backing.
Thanks,
Andrea
next prev parent reply other threads:[~2026-10-20 15:17 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-14 17:00 [PATCH blktests 0/4] nvme: add nvmet zone report and FC regression tests Andrea Parri
2026-10-14 17:00 ` [PATCH blktests 1/4] nvme/rc: add zoned null_blk target helpers Andrea Parri
2026-10-20 10:31 ` Shin'ichiro Kawasaki
2026-10-14 17:00 ` [PATCH blktests 2/4] nvme/071: test that nvmet sends no data for a failed read Andrea Parri
2026-10-20 10:35 ` Shin'ichiro Kawasaki
2026-10-20 15:17 ` Andrea Parri [this message]
2026-10-14 17:00 ` [PATCH blktests 3/4] nvme/072: test nvmet zone report initialization and length Andrea Parri
2026-10-20 10:38 ` Shin'ichiro Kawasaki
2026-10-14 17:00 ` [PATCH blktests 4/4] nvme/073: test that nvmet rejects a zone report NUMD that wraps Andrea Parri
2026-10-20 10:41 ` [PATCH blktests 0/4] nvme: add nvmet zone report and FC regression tests Shin'ichiro Kawasaki
2026-10-20 15:18 ` Andrea Parri
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=20261020151732.90412-1-parri.andrea@gmail.com \
--to=parri.andrea@gmail.com \
--cc=dwagner@suse.de \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=kch@nvidia.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
--cc=shinichiro.kawasaki@wdc.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