From: Joanne Koong <joannelkoong@gmail.com>
To: brauner@kernel.org
Cc: djwong@kernel.org, hch@infradead.org, willy@infradead.org,
wegao@suse.com, sashal@kernel.org, stable@vger.kernel.org,
linux-fsdevel@vger.kernel.org
Subject: [PATCH v2 0/1] iomap: don't mark folio uptodate if read IO has bytes pending
Date: Tue, 3 Mar 2026 15:34:19 -0800 [thread overview]
Message-ID: <20260303233420.874231-1-joannelkoong@gmail.com> (raw)
This is a fix for this scenario:
->read_folio() gets called on a folio size that is 16k while the file is 4k:
a) ifs->read_bytes_pending gets initialized to 16k
b) ->read_folio_range() is called for the 4k read
c) the 4k read succeeds, ifs->read_bytes_pending is now 12k and the
0 to 4k range is marked uptodate
d) the post-eof blocks are zeroed and marked uptodate in the call to
iomap_set_range_uptodate()
e) iomap_set_range_uptodate() sees all the ranges are marked
uptodate and it marks the folio uptodate
f) iomap_read_end() gets called to subtract the 12k from
ifs->read_bytes_pending. it too sees all the ranges are marked
uptodate and marks the folio uptodate using XOR
g) the XOR call clears the uptodate flag on the folio
The same situation can occur if the last range read for the folio is done as
an inline read and all the previous ranges have already completed by the time
the inline read completes.
For more context, the full discussion can be found in [1]. There was a
discussion about alternative approaches in that thread, but they had more
complications.
There is another discussion in v1 [2] about consolidating the read paths.
Until that is resolved, this patch fixes the issue.
Thanks,
Joanne
[1] https://lore.kernel.org/linux-fsdevel/CAJnrk1Z9za5w4FoJqTGx50zR2haHHaoot1KJViQyEHJQq4=34w@mail.gmail.com/#t
[2] https://lore.kernel.org/linux-fsdevel/20260219003911.344478-1-joannelkoong@gmail.com/T/#u
Changelog
---------
v1: https://lore.kernel.org/linux-fsdevel/20260219003911.344478-1-joannelkoong@gmail.com/T/#u
Changes made to v1:
* Add Darrick's reviewed-by, cc stable@, add link to discussion to commit
message (Darrick)
Joanne Koong (1):
iomap: don't mark folio uptodate if read IO has bytes pending
fs/iomap/buffered-io.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
--
2.47.3
next reply other threads:[~2026-03-03 23:35 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-03 23:34 Joanne Koong [this message]
2026-03-03 23:34 ` [PATCH v2 1/1] iomap: don't mark folio uptodate if read IO has bytes pending Joanne Koong
2026-03-04 13:19 ` [PATCH v2 0/1] " Christian Brauner
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=20260303233420.874231-1-joannelkoong@gmail.com \
--to=joannelkoong@gmail.com \
--cc=brauner@kernel.org \
--cc=djwong@kernel.org \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=sashal@kernel.org \
--cc=stable@vger.kernel.org \
--cc=wegao@suse.com \
--cc=willy@infradead.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.