summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/bin/git@git.tavy.me:linux.git
diff options
context:
space:
mode:
authorBrian Foster <bfoster@redhat.com>2025-12-08 09:05:48 -0500
committerChristian Brauner <brauner@kernel.org>2025-12-15 15:17:44 +0100
commited61378b4dc63efe76cb8c23a36b228043332da3 (patch)
tree548d6796542c232cf3d45438ee79e092c627df0e /tools/perf/scripts/python/bin/git@git.tavy.me:linux.git
parenta260bd22a355bcdb74cedac6ab9b10739cd2c62c (diff)
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>
Diffstat (limited to 'tools/perf/scripts/python/bin/git@git.tavy.me:linux.git')
0 files changed, 0 insertions, 0 deletions