ext4: skip block allocation for holes in the data submission path

When ext4_map_blocks() is called from the data submission path and I/O
end extent conversion path (EXT4_GET_BLOCKS_IO_SUBMIT), it should not
allocate blocks if the lookup returns a hole.

The writeback path can legitimately encounter dirty ranges that map to
holes. For example, when a folio straddles i_size and the tail beyond
i_size is dirtied via a mmap write. Allocating blocks for such ranges is
wrong because there is no data to write back, the dirty bits should
simply be discarded without submitting I/O.

This prepares for the buffered iomap writeback conversion, mirrors the
existing buffer_head writeback path, where mpage_add_bh_to_extent() skip
unmapped buffers and ext4_bio_write_folio() clears their dirty bits.
Since ext4_map_blocks() can now return zero for a hole,
mpage_map_one_extent() must handle it as well. However, because those
holes are already filtered out by mpage_add_bh_to_extent(), it only maps
buffers that are delayed or unwritten, so a hole can never occur in
normal operation. Add a WARN_ON_ONCE() and bail out with -EINVAL rather
than proceeding with an invalid physical block number of zero.

In the ioend extent conversion path, holes are also not expected because
we should wait for folio writeback before punching hole. If one is
encountered, it likely indicates a failure in the concurrency
protection, so ext4_map_blocks() returns zero, and we keep warning and
bail out with -EINVAL to surface the failure rather than continuing
conversion on torn data. Atomic writes in
ext4_convert_unwritten_extents_atomic() already bail out similarly.

Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
Reviewed-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Tested-by: syzbot@syzkaller.appspotmail.com
Link: https://patch.msgid.link/20261009103033.2920530-9-yi.zhang@huaweicloud.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>

0 files changed, 0 insertions, 0 deletions