diff options
author | Brian Foster <bfoster@redhat.com> | 2024-11-15 17:59:31 +0300 |
---|---|---|
committer | Christian Brauner <brauner@kernel.org> | 2024-11-21 11:35:24 +0300 |
commit | eb65540aa9fc828e9f3f8b30d6dc37f1ed35263d (patch) | |
tree | 188fe1af7a7669d02ca95409517812f9be478012 /tools/perf/scripts/python | |
parent | f13242a46438e690067a4bf47068fde4d5719947 (diff) | |
download | linux-eb65540aa9fc828e9f3f8b30d6dc37f1ed35263d.tar.xz |
iomap: warn on zero range of a post-eof folio
iomap_zero_range() uses buffered writes for manual zeroing, no
longer updates i_size for such writes, but is still explicitly
called for post-eof ranges. The historical use case for this is
zeroing post-eof speculative preallocation on extending writes from
XFS. However, XFS also recently changed to convert all post-eof
delalloc mappings to unwritten in the iomap_begin() handler, which
means it now never expects manual zeroing of post-eof mappings. In
other words, all post-eof mappings should be reported as holes or
unwritten.
This is a subtle dependency that can be hard to detect if violated
because associated codepaths are likely to update i_size after folio
locks are dropped, but before writeback happens to occur. For
example, if XFS reverts back to some form of manual zeroing of
post-eof blocks on write extension, writeback of those zeroed folios
will now race with the presumed i_size update from the subsequent
buffered write.
Since iomap_zero_range() can't correctly zero post-eof mappings
beyond EOF without updating i_size, warn if this ever occurs. This
serves as minimal indication that if this use case is reintroduced
by a filesystem, iomap_zero_range() might need to reconsider i_size
updates for write extending use cases.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Link: https://lore.kernel.org/r/20241115145931.535207-1-bfoster@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')
0 files changed, 0 insertions, 0 deletions