]> git.ipfire.org Git - thirdparty/kernel/linux.git/commit
iomap: replace folio_batch allocation with stack allocation
authorBrian Foster <bfoster@redhat.com>
Mon, 8 Dec 2025 14:05:48 +0000 (09:05 -0500)
committerChristian Brauner <brauner@kernel.org>
Mon, 15 Dec 2025 14:17:44 +0000 (15:17 +0100)
commited61378b4dc63efe76cb8c23a36b228043332da3
tree548d6796542c232cf3d45438ee79e092c627df0e
parenta260bd22a355bcdb74cedac6ab9b10739cd2c62c
iomap: replace folio_batch allocation with stack allocation

Zhang Yi points out that the dynamic folio_batch allocation in
iomap_fill_dirty_folios() is problematic for the ext4 on iomap work
that is under development because it doesn't sufficiently handle the
allocation failure case (by allowing a retry, for example). We've
also seen lockdep (via syzbot) complain recently about the scope of
the allocation.

The dynamic allocation was initially added for simplicity and to
help indicate whether the batch was used or not by the calling fs.
To address these issues, put the batch on the stack of
iomap_zero_range() and use a flag to control whether the batch
should be used in the iomap folio lookup path. This keeps things
simple and eliminates allocation issues with lockdep and for ext4 on
iomap.

While here, also clean up the fill helper signature to be more
consistent with the underlying filemap helper. Pass through the
return value of the filemap helper (folio count) and update the
lookup offset via an out param.

Fixes: 395ed1ef0012 ("iomap: optional zero range dirty folio processing")
Signed-off-by: Brian Foster <bfoster@redhat.com>
Link: https://patch.msgid.link/20251208140548.373411-1-bfoster@redhat.com
Acked-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Christian Brauner <brauner@kernel.org>
fs/iomap/buffered-io.c
fs/iomap/iter.c
fs/xfs/xfs_iomap.c
include/linux/iomap.h