From: Piyush Patle <piyushpatle228@gmail.com>
To: brauner@kernel.org
Cc: djwong@kernel.org, linux-xfs@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
syzbot+bd5ca596a01d01bfa083@syzkaller.appspotmail.com
Subject: [PATCH] iomap: handle iterator position advancing beyond current mapping
Date: Mon, 2 Feb 2026 21:14:53 +0530 [thread overview]
Message-ID: <20260202154453.650471-1-piyushpatle228@gmail.com> (raw)
In-Reply-To: <20260202130044.567989-1-piyushpatle228@gmail.com>
iomap_iter_done() expects that the iterator position always lies within
the current iomap range. However, during buffered writes combined with
truncate or overwrite operations, the iterator position can advance past
the end of the current iomap without the mapping being invalidated.
When this happens, iomap_iter_done() triggers a warning because
iomap.offset + iomap.length no longer covers iter->pos, even though this
state can legitimately occur due to extent invalidation or write completion
advancing the iterator position.
Detect this condition immediately after iomap_begin(), mark the mapping
as stale, reset the iterator state, and retry mapping from the current
position. This ensures that iomap_end() invariants are preserved and
prevents spurious warnings.
Fixes: a66191c590b3b58eaff05d2277971f854772bd5b ("iomap: tighten iterator state validation")
Tested-by: Piyush Patle <piyushpatle288@gmail.com>
Signed-off-by: Piyush Patle <piyushpatle228@gmail.com>
Reported-by: syzbot+bd5ca596a01d01bfa083@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=bd5ca596a01d01bfa083
---
fs/iomap/iter.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/fs/iomap/iter.c b/fs/iomap/iter.c
index c04796f6e57f..466a12b0c094 100644
--- a/fs/iomap/iter.c
+++ b/fs/iomap/iter.c
@@ -111,6 +111,13 @@ int iomap_iter(struct iomap_iter *iter, const struct iomap_ops *ops)
&iter->iomap, &iter->srcmap);
if (ret < 0)
return ret;
+ if (iter->iomap.length &&
+ iter->iomap.offset + iter->iomap.length <= iter->pos) {
+ iter->iomap.flags |= IOMAP_F_STALE;
+ iomap_iter_reset_iomap(iter);
+ return 1;
+ }
+
iomap_iter_done(iter);
return 1;
}
--
2.34.1
prev parent reply other threads:[~2026-02-02 15:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-02 13:00 [PATCH] iomap: handle iterator position advancing beyond current mapping Piyush Patle
2026-02-02 14:48 ` Christoph Hellwig
2026-02-02 15:35 ` Matthew Wilcox
2026-02-02 16:05 ` Christoph Hellwig
2026-02-02 18:34 ` Brian Foster
2026-02-02 15:40 ` Piyush Patle
2026-02-02 15:44 ` Piyush Patle [this message]
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=20260202154453.650471-1-piyushpatle228@gmail.com \
--to=piyushpatle228@gmail.com \
--cc=brauner@kernel.org \
--cc=djwong@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=syzbot+bd5ca596a01d01bfa083@syzkaller.appspotmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox