All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: linux-fsdevel@vger.kernel.org
Subject: [PATCH v3 4/4] iomap: warn on zero range of a post-eof folio
Date: Fri,  8 Nov 2024 07:42:46 -0500	[thread overview]
Message-ID: <20241108124246.198489-5-bfoster@redhat.com> (raw)
In-Reply-To: <20241108124246.198489-1-bfoster@redhat.com>

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);
 		offset = offset_in_folio(folio, pos);
 		if (bytes > folio_size(folio) - offset)
 			bytes = folio_size(folio) - offset;
-- 
2.47.0


  parent reply	other threads:[~2024-11-08 12:41 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 ` Brian Foster [this message]
2024-11-09  3:06   ` [PATCH v3 4/4] iomap: warn on zero range of a post-eof folio Darrick J. Wong
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=20241108124246.198489-5-bfoster@redhat.com \
    --to=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.