Re: [PATCH blktests v2 4/4] block/052: add a torn atomic write test for block devices

[John Garry <john.garry@linux.dev>]

On 10/10/26 00:53, Tal Zussman wrote:
> An atomic write is submitted as a single bio,

nit: A HW-based atomic write is always a single bio. A SW-based atomic 
write - like which xfs supports - does not have such a limit.

> so when its buffer can't
> be fully pinned, the direct I/O path has to fail the write rather than
> submit the pinned part. Otherwise, it submits what was pinned with
> REQ_ATOMIC set and leaves the rest to the buffered fallback, tearing the
> write at the pin boundary.
> 
> This is a regression test for that issue, fixed in the kernel patch
> "block: fail a short atomic pin in bio_iov_iter_get_pages()" [1].
> 
> Issue pwritev2() with RWF_ATOMIC to a scsi_debug device with atomic_wr=1
> from a buffer whose last page is PROT_NONE, so that pinning the buffer
> stops one page short, then read the range back with O_DIRECT and fail if
> it holds a mix of old and new data.
> 
> The write has to span at least two pages so that one can be left
> unpinnable, and the device has to support it atomically. Use the largest
> power of two up to 16K that the device's atomic write unit max allows,
> and skip the test if that is below two pages.

As you probably saw, we have other atomic writes tests and they use 
xfsprogs (xfs_io, specifically) to issue the atomic write and statx.

Is there scope to use xfsprogs again here? I suppose that the gap is the 
mmap and mprotect call.