On Mon, 21 Sept 2026 at 14:40, Shin'ichiro Kawasaki
[off-list ref] wrote:
I found that recent blktests CI trial runs started reporting the failure of
the test case block/046 [1]. I confirmed that it is observed with the kernel at
the linux-block for-next branch. I bisected and found the this commit triggers
the failure. The error message "preadv returned -1 (errno 22)" was printed at
src/bio-bounce-read.c line 121 [2].
Thanks for the report. I've taken a look at the v3 series. block/046
deliberately uses iovec lengths of 1, one logical block, and one logical
block minus 1 to create the partial extraction state that exposed the
original double unpin.
Patch 13 stops passing IOMAP_DIO_BOUNCE to iomap_dio_rw(), so the
request now goes through the ordinary bio_iov_iter_get_pages() path
first. That path validates each iovec against bdev_dma_alignment(),
and the one-byte first iovec is rejected with EINVAL before it is
pinned and before xfs_ioend_submit_read() can select lazy or always
bounce mode.
AFAIU, the test case does direct read to a null_blk with bounce buffer, and the
kernel side introduced some new requirements to use bounce buffer for direct
I/Os. Then, I guess the test case requires some refinements to meet the new
requirements.
0wnerD1ed, may I ask your help to fix this failure? At this moment, I don't have
much time to dig into this.
Setting csum/read_bounce to always therefore would not make this
particular request reach the new bounce implementation. Patch 16 also
removes bio_iov_iter_bounce_read(), including the special bvec layout
that block/046 was written to exercise. Changing the helper to use
aligned input and forcing always mode would test the replacement iomap
implementation, but it would not preserve coverage of the original
regression.
I have prepared a minimal local blktests change that keeps block/046
active on kernels using the legacy implementation and marks it not run
when the mounted XFS instance exposes the new csum/read_bounce
interface. That preserves the existing fixed-versus-vulnerable
coverage without treating EINVAL as a successful result. A separate
test could cover the new lazy and always implementations with aligned
input and an oracle appropriate to those paths.