From: "Darrick J. Wong" <djwong@kernel.org>
To: Brian Foster <bfoster@redhat.com>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v3 4/4] iomap: warn on zero range of a post-eof folio
Date: Fri, 8 Nov 2024 19:06:23 -0800 [thread overview]
Message-ID: <20241109030623.GD9421@frogsfrogsfrogs> (raw)
In-Reply-To: <20241108124246.198489-5-bfoster@redhat.com>
On Fri, Nov 08, 2024 at 07:42:46AM -0500, Brian Foster wrote:
> 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>
> ---
> fs/iomap/buffered-io.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
> index 7f40234a301e..e18830e4809b 100644
> --- a/fs/iomap/buffered-io.c
> +++ b/fs/iomap/buffered-io.c
> @@ -1354,6 +1354,7 @@ static loff_t iomap_zero_iter(struct iomap_iter *iter, bool *did_zero)
> {
> loff_t pos = iter->pos;
> loff_t length = iomap_length(iter);
> + loff_t isize = iter->inode->i_size;
> loff_t written = 0;
>
> do {
> @@ -1369,6 +1370,8 @@ static loff_t iomap_zero_iter(struct iomap_iter *iter, bool *did_zero)
> if (iter->iomap.flags & IOMAP_F_STALE)
> break;
>
> + /* warn about zeroing folios beyond eof that won't write back */
> + WARN_ON_ONCE(folio_pos(folio) > isize);
WARN_ON_ONCE(folio_pos(folio) > iter->inode->i_size));?
No need to have the extra local variable for something that shouldn't
ever happen. Do you need i_size_read for correctness here?
--D
> offset = offset_in_folio(folio, pos);
> if (bytes > folio_size(folio) - offset)
> bytes = folio_size(folio) - offset;
> --
> 2.47.0
>
>
next prev parent reply other threads:[~2024-11-09 3:06 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-08 12:42 [PATCH v3 0/4] iomap: zero range flush fixes Brian Foster
2024-11-08 12:42 ` [PATCH v3 1/4] iomap: reset per-iter state on non-error iter advances Brian Foster
2024-11-09 3:00 ` Darrick J. Wong
2024-11-11 5:53 ` Christoph Hellwig
2024-11-12 13:59 ` Brian Foster
2024-11-08 12:42 ` [PATCH v3 2/4] iomap: lift zeroed mapping handling into iomap_zero_range() Brian Foster
2024-11-09 3:01 ` Darrick J. Wong
2024-11-12 13:59 ` Brian Foster
2024-11-11 6:03 ` Christoph Hellwig
2024-11-12 14:00 ` Brian Foster
2024-11-15 14:53 ` Brian Foster
2024-11-15 17:02 ` Darrick J. Wong
2024-11-15 19:31 ` Brian Foster
2024-11-08 12:42 ` [PATCH v3 3/4] iomap: elide flush from partial eof zero range Brian Foster
2024-11-09 3:03 ` Darrick J. Wong
2024-11-11 6:06 ` Christoph Hellwig
2024-11-08 12:42 ` [PATCH v3 4/4] iomap: warn on zero range of a post-eof folio Brian Foster
2024-11-09 3:06 ` Darrick J. Wong [this message]
2024-11-12 14:01 ` Brian Foster
2024-11-11 6:06 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241109030623.GD9421@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=bfoster@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.