dd iflag=direct reads fail with "IO error: Invalid input" on devices with strict dma_alignment

[chrboe]

dd … iflag=direct fails with IO error: Invalid input when reading from a block device whose /sys/block/X/queue/dma_alignment is >= 511, even for fully aligned offsets and aligned I/O sizes. The read-side I/O buffer is allocated with default heap alignment (~16 bytes) instead of being aligned to the device's dma_alignment requirement, so the kernel rejects the O_DIRECT read with EINVAL.

This is related to #9003 / #9016. PR #9016 fixed the write path (partial-block writes at end-of-output). The read path still under-aligns its buffer; both bs=4K count=1 from offset 0 and large multi-block reads fail.

Originally spotted with DRBD, but this reproduces with all block device drivers that set dma_alignment to 511. For example, loop, virtio_blk, brd, nbd, zram are all affected.

Reproducer

Tested on Ubuntu 26.04 (resolute) with dd (uutils coreutils) 0.8.0, rust-coreutils 0.8.0-0ubuntu3, kernel 7.0.0-14-generic.

$ truncate -s 1M /tmp/loop.img
$ losetup --find --show /tmp/loop.img
/dev/loop0
$ cat /sys/block/loop0/queue/dma_alignment
511
$ dd if=/dev/loop0 of=/dev/null bs=4K count=1 iflag=direct
dd: IO error: Invalid input

Sanity check, the same read works with GNU dd:

$ gnudd --version
dd (coreutils) 9.7
Packaged by Ubuntu (9.7-3ubuntu2)
$ gnudd if=/dev/loop0 of=/dev/null bs=4K count=1 iflag=direct
1+0 records in
1+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 6.258e-05 s, 65.5 MB/s

[chrboe]

Can also reproduce with the latest build:

$ wget https://github.com/uutils/coreutils/releases/download/latest-commit/individual-x86_64-unknown-linux-gnu.tar.zst
$ tar xf individual-x86_64-unknown-linux-gnu.tar.zst
$ cd bin
$ ./dd if=/dev/loop0 of=/dev/null bs=4K count=1 iflag=direct
dd: IO error: Invalid input

[Franklin-Qi]

I also reproduced the dd command error on Ubuntu 26.04.

$ sudo dd if=/dev/loop0 of=/dev/null bs=4K count=1 iflag=direct 
dd: IO error: Invalid input

$ sudo gnudd if=/dev/loop0 of=/dev/null bs=4K count=1 iflag=direct 
1+0 records in
1+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 0.000154585 s, 26.5 MB/s

[chrboe]

Just to add some more context, here is a "Critical" Ubuntu bug report detailing a resource-agents test failure because of this issue: https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bug/2125968

This could completely break many HA deployments using resource-agents (such as Pacemaker clusters). The Filesystem monitor action uses the exact pattern that is broken here: https://github.com/ClusterLabs/resource-agents/blob/main/heartbeat/Filesystem#L1074

$DEVICE in this context will commonly be a DRBD device, so the bug will trigger in most cases.

[relative23]

Root cause confirmed: the copy-loop buffer is a plain Vec<u8> (16-byte aligned with glibc), while these devices require sector alignment (dma_alignment=511). Note the write path is affected as well, just masked: every full-block oflag=direct write first fails with EINVAL and is silently retried buffered through the fcntl fallback, so oflag=direct currently does no direct I/O at all and costs three extra syscalls per block.

Opened #13373, which fixes both by page-aligning the buffer (GNU-style), implemented without unsafe.