Re: [PATCH v2 5/7] block: fail atomic writes instead of falling back to buffered I/O

[Christoph Hellwig <hch@lst.de>]

On Fri, Aug 28, 2026 at 09:49:54AM -0400, Tal Zussman wrote:
> An IOCB_ATOMIC direct write to a block device can silently lose its
> torn-write guarantee in two ways:
> 
>   1. blkdev_direct_write() turns an -EBUSY from page cache invalidation
>      into a 0 return, so the whole write is retried through
>      blkdev_buffered_write(), with no atomicity guarantee.
> 
>   2. On a partial page pin, __blkdev_direct_IO_simple() and
>      __blkdev_direct_IO_async() submit what was pinned with REQ_ATOMIC
>      set and leave the rest to the buffered fallback.
> 
> The second case can be triggered deterministically. A 16K
> pwritev2(RWF_ATOMIC) whose last page is PROT_NONE, on a scsi_debug
> device with atomic_wr=1, completes short with only three of the four
> pages written, violating RWF_ATOMIC semantics.
> 
> Fail the I/O instead. Return -EAGAIN when page cache invalidation fails
> for IOCB_ATOMIC rather than retrying through the page cache, matching
> __iomap_dio_rw(), which treats the failure as transient and lets the
> caller retry. Release a short atomic pin and return -EFAULT before
> submission, which is what a direct write already returns when none of
> the buffer can be pinned. A sync atomic write can then never return
> short with a remainder, so the buffered fallback is never reached.
> 
> ext4 has the same fallback and only warns in it. For block devices both
> ways in can be detected before any I/O is submitted, so fail early instead.

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

The fallback in ext4 looks dangerous, it might be worth bringing
that to the maintainers attention.