* [PATCH] iomap: adjust read range correctly for non-block-aligned positions
@ 2025-09-22 18:00 Joanne Koong
2025-09-22 18:21 ` Christoph Hellwig
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: Joanne Koong @ 2025-09-22 18:00 UTC (permalink / raw)
To: brauner; +Cc: djwong, hch, bfoster, linux-fsdevel, syzbot
iomap_adjust_read_range() assumes that the position and length passed in
are block-aligned. This is not always the case however, as shown in the
syzbot generated case for erofs. This causes too many bytes to be
skipped for uptodate blocks, which results in returning the incorrect
position and length to read in. If all the blocks are uptodate, this
underflows length and returns a position beyond the folio.
Fix the calculation to also take into account the block offset when
calculating how many bytes can be skipped for uptodate blocks.
Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
Tested-by: syzbot@syzkaller.appspotmail.com
---
fs/iomap/buffered-io.c | 19 +++++++++++++------
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
index 8b847a1e27f1..1c95a0a7b302 100644
--- a/fs/iomap/buffered-io.c
+++ b/fs/iomap/buffered-io.c
@@ -240,17 +240,24 @@ static void iomap_adjust_read_range(struct inode *inode, struct folio *folio,
* to avoid reading in already uptodate ranges.
*/
if (ifs) {
- unsigned int i;
+ unsigned int i, blocks_skipped;
/* move forward for each leading block marked uptodate */
- for (i = first; i <= last; i++) {
+ for (i = first; i <= last; i++)
if (!ifs_block_is_uptodate(ifs, i))
break;
- *pos += block_size;
- poff += block_size;
- plen -= block_size;
- first++;
+
+ blocks_skipped = i - first;
+ if (blocks_skipped) {
+ unsigned long block_offset = *pos & (block_size - 1);
+ unsigned bytes_skipped =
+ (blocks_skipped << block_bits) - block_offset;
+
+ *pos += bytes_skipped;
+ poff += bytes_skipped;
+ plen -= bytes_skipped;
}
+ first = i;
/* truncate len if we find any trailing uptodate block(s) */
while (++i <= last) {
--
2.47.3
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] iomap: adjust read range correctly for non-block-aligned positions
2025-09-22 18:00 [PATCH] iomap: adjust read range correctly for non-block-aligned positions Joanne Koong
@ 2025-09-22 18:21 ` Christoph Hellwig
2025-09-25 13:46 ` Brian Foster
2025-09-29 9:35 ` Christian Brauner
2 siblings, 0 replies; 4+ messages in thread
From: Christoph Hellwig @ 2025-09-22 18:21 UTC (permalink / raw)
To: Joanne Koong; +Cc: brauner, djwong, hch, bfoster, linux-fsdevel, syzbot
On Mon, Sep 22, 2025 at 11:00:42AM -0700, Joanne Koong wrote:
> iomap_adjust_read_range() assumes that the position and length passed in
> are block-aligned. This is not always the case however, as shown in the
> syzbot generated case for erofs. This causes too many bytes to be
> skipped for uptodate blocks, which results in returning the incorrect
> position and length to read in. If all the blocks are uptodate, this
> underflows length and returns a position beyond the folio.
>
> Fix the calculation to also take into account the block offset when
> calculating how many bytes can be skipped for uptodate blocks.
>
> Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
> Tested-by: syzbot@syzkaller.appspotmail.com
Looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] iomap: adjust read range correctly for non-block-aligned positions
2025-09-22 18:00 [PATCH] iomap: adjust read range correctly for non-block-aligned positions Joanne Koong
2025-09-22 18:21 ` Christoph Hellwig
@ 2025-09-25 13:46 ` Brian Foster
2025-09-29 9:35 ` Christian Brauner
2 siblings, 0 replies; 4+ messages in thread
From: Brian Foster @ 2025-09-25 13:46 UTC (permalink / raw)
To: Joanne Koong; +Cc: brauner, djwong, hch, linux-fsdevel, syzbot
On Mon, Sep 22, 2025 at 11:00:42AM -0700, Joanne Koong wrote:
> iomap_adjust_read_range() assumes that the position and length passed in
> are block-aligned. This is not always the case however, as shown in the
> syzbot generated case for erofs. This causes too many bytes to be
> skipped for uptodate blocks, which results in returning the incorrect
> position and length to read in. If all the blocks are uptodate, this
> underflows length and returns a position beyond the folio.
>
> Fix the calculation to also take into account the block offset when
> calculating how many bytes can be skipped for uptodate blocks.
>
> Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
> Tested-by: syzbot@syzkaller.appspotmail.com
> ---
Reviewed-by: Brian Foster <bfoster@redhat.com>
> fs/iomap/buffered-io.c | 19 +++++++++++++------
> 1 file changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
> index 8b847a1e27f1..1c95a0a7b302 100644
> --- a/fs/iomap/buffered-io.c
> +++ b/fs/iomap/buffered-io.c
> @@ -240,17 +240,24 @@ static void iomap_adjust_read_range(struct inode *inode, struct folio *folio,
> * to avoid reading in already uptodate ranges.
> */
> if (ifs) {
> - unsigned int i;
> + unsigned int i, blocks_skipped;
>
> /* move forward for each leading block marked uptodate */
> - for (i = first; i <= last; i++) {
> + for (i = first; i <= last; i++)
> if (!ifs_block_is_uptodate(ifs, i))
> break;
> - *pos += block_size;
> - poff += block_size;
> - plen -= block_size;
> - first++;
> +
> + blocks_skipped = i - first;
> + if (blocks_skipped) {
> + unsigned long block_offset = *pos & (block_size - 1);
> + unsigned bytes_skipped =
> + (blocks_skipped << block_bits) - block_offset;
> +
> + *pos += bytes_skipped;
> + poff += bytes_skipped;
> + plen -= bytes_skipped;
> }
> + first = i;
>
> /* truncate len if we find any trailing uptodate block(s) */
> while (++i <= last) {
> --
> 2.47.3
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] iomap: adjust read range correctly for non-block-aligned positions
2025-09-22 18:00 [PATCH] iomap: adjust read range correctly for non-block-aligned positions Joanne Koong
2025-09-22 18:21 ` Christoph Hellwig
2025-09-25 13:46 ` Brian Foster
@ 2025-09-29 9:35 ` Christian Brauner
2 siblings, 0 replies; 4+ messages in thread
From: Christian Brauner @ 2025-09-29 9:35 UTC (permalink / raw)
To: Joanne Koong
Cc: Christian Brauner, djwong, hch, bfoster, linux-fsdevel, syzbot
On Mon, 22 Sep 2025 11:00:42 -0700, Joanne Koong wrote:
> iomap_adjust_read_range() assumes that the position and length passed in
> are block-aligned. This is not always the case however, as shown in the
> syzbot generated case for erofs. This causes too many bytes to be
> skipped for uptodate blocks, which results in returning the incorrect
> position and length to read in. If all the blocks are uptodate, this
> underflows length and returns a position beyond the folio.
>
> [...]
Applied to the vfs-6.19.iomap branch of the vfs/vfs.git tree.
Patches in the vfs-6.19.iomap branch should appear in linux-next soon.
Please report any outstanding bugs that were missed during review in a
new review to the original patch series allowing us to drop it.
It's encouraged to provide Acked-bys and Reviewed-bys even though the
patch has now been applied. If possible patch trailers will be updated.
Note that commit hashes shown below are subject to change due to rebase,
trailer updates or similar. If in doubt, please check the listed branch.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git
branch: vfs-6.19.iomap
[1/1] iomap: adjust read range correctly for non-block-aligned positions
https://git.kernel.org/vfs/vfs/c/94b11133d6f6
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2025-09-29 9:35 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-09-22 18:00 [PATCH] iomap: adjust read range correctly for non-block-aligned positions Joanne Koong
2025-09-22 18:21 ` Christoph Hellwig
2025-09-25 13:46 ` Brian Foster
2025-09-29 9:35 ` Christian Brauner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).