From: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
To: Tal Zussman <tz2294@columbia.edu>
Cc: John Garry <john.garry@linux.dev>,
linux-block@vger.kernel.org, Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH blktests v3 4/4] block/053: add a torn atomic write test for block devices
Date: Fri, 30 Oct 2026 11:12:02 +0900 [thread overview]
Message-ID: <auP5md9PBSJnZDND@shinmob> (raw)
In-Reply-To: <5b4621c2-f707-4644-8aeb-d4d0956317c7@columbia.edu>
On Oct 30, 2026 / 01:15, Tal Zussman wrote:
> On 10/16/26 4:53 AM, John Garry wrote:
> >
> > thanks, just some more comments
> >
>
> Thanks, I'll address all of the below.
>
> ...
>
> >> +#ifndef RWF_ATOMIC
> >> +#define RWF_ATOMIC 0x00000040
> >> +#endif
> >> +
> >> +#ifndef STATX_WRITE_ATOMIC
> >> +#define STATX_WRITE_ATOMIC 0x00010000U
> >> +#endif
> >> +#ifndef STATX_ATTR_WRITE_ATOMIC
> >> +#define STATX_ATTR_WRITE_ATOMIC 0x00400000
> >> +#endif
> >> +
> >
> > Do we still really need these? Surely a test machine will be installing
> > the latest headers along with the new kernel, no?
> >
> I would assume so, but src/metadata.c and src/metadata-iopoll.c also redefine
> various structs/flags from kernel headers, so it seems like that may not be
> the case.
>
> Shin'ichiro, any guidance?
First of all, blktests targets not only the latest kernels but also older stable
kernels. I expect the make command for blktests can build src/* binaries without
failures regardless of the kernel header versions installed.
The #ifndef approach above can avoid the build failure with old headers, so I
think it is acceptable. The other approach is to check the relevant C macro
definitions in src/Makefile as it does for UBLK_U_CMD_START_DEV. This is more
ideal since the unnecessary binary is not built for older kernels, but it will
add some complexity in the Makefile. Either way is fine for me.
next prev parent reply other threads:[~2026-10-30 2:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-15 16:29 [PATCH blktests v3 0/4] blktests: tests for the direct I/O fallback, splice, bio trimming, and atomic write fixes Tal Zussman
2026-10-15 16:29 ` [PATCH blktests v3 1/4] block/050: add a direct I/O write fallback race test for block devices Tal Zussman
2026-10-15 16:29 ` [PATCH blktests v3 2/4] block/051: add a splice read " Tal Zussman
2026-10-15 16:29 ` [PATCH blktests v3 3/4] block/052: add a pinned page leak test for trimmed direct writes Tal Zussman
2026-10-15 16:29 ` [PATCH blktests v3 4/4] block/053: add a torn atomic write test for block devices Tal Zussman
2026-10-16 8:53 ` John Garry
2026-10-29 23:15 ` Tal Zussman
2026-10-30 2:12 ` Shin'ichiro Kawasaki [this message]
2026-10-30 22:52 ` Tal Zussman
2026-10-27 7:42 ` [PATCH blktests v3 0/4] blktests: tests for the direct I/O fallback, splice, bio trimming, and atomic write fixes Shin'ichiro Kawasaki
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=auP5md9PBSJnZDND@shinmob \
--to=shinichiro.kawasaki@wdc.com \
--cc=hch@lst.de \
--cc=john.garry@linux.dev \
--cc=linux-block@vger.kernel.org \
--cc=tz2294@columbia.edu \
/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