[PATCH v1] iomap: fix invalid folio access when i_blkbits differs from I/O granularity

[PATCH v1] iomap: fix invalid folio access when i_blkbits differs from I/O granularity

[Joanne Koong]

Commit aa35dd5cbc06 ("iomap: fix invalid folio access after
folio_end_read()") partially addressed invalid folio access for folios
without an ifs attached, but it did not handle the case where
1 << inode->i_blkbits matches the folio size but is different from the
granularity used for the IO, which means IO can be submitted for less
than the full folio for the !ifs case.

In this case, the condition:

  if (*bytes_submitted == folio_len)
    ctx->cur_folio = NULL;

in iomap_read_folio_iter() will not invalidate ctx->cur_folio, and
iomap_read_end() will still be called on the folio even though the IO
helper owns it and will finish the read on it.

Fix this by unconditionally invalidating ctx->cur_folio for the !ifs
case.

Reported-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Tested-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Link: https://lore.kernel.org/linux-fsdevel/b3dfe271-4e3d-4922-b618-e73731242bca@wdc.com/
Fixes: b2f35ac4146d ("iomap: add caller-provided callbacks for read and readahead")
Cc: stable@vger.kernel.org
Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
---
 fs/iomap/buffered-io.c | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
index 3cf93ab2e38a..e4b6886e5c3c 100644
--- a/fs/iomap/buffered-io.c
+++ b/fs/iomap/buffered-io.c
@@ -514,6 +514,7 @@ static int iomap_read_folio_iter(struct iomap_iter *iter,
 	loff_t length = iomap_length(iter);
 	struct folio *folio = ctx->cur_folio;
 	size_t folio_len = folio_size(folio);
+	struct iomap_folio_state *ifs;
 	size_t poff, plen;
 	loff_t pos_diff;
 	int ret;
@@ -525,7 +526,7 @@ static int iomap_read_folio_iter(struct iomap_iter *iter,
 		return iomap_iter_advance(iter, length);
 	}
 
-	ifs_alloc(iter->inode, folio, iter->flags);
+	ifs = ifs_alloc(iter->inode, folio, iter->flags);
 
 	length = min_t(loff_t, length, folio_len - offset_in_folio(folio, pos));
 	while (length) {
@@ -560,11 +561,15 @@ static int iomap_read_folio_iter(struct iomap_iter *iter,
 
 			*bytes_submitted += plen;
 			/*
-			 * If the entire folio has been read in by the IO
-			 * helper, then the helper owns the folio and will end
-			 * the read on it.
+			 * Hand off folio ownership to the IO helper when:
+			 * 1) The entire folio has been submitted for IO, or
+			 * 2) There is no ifs attached to the folio
+			 *
+			 * Case (2) occurs when 1 << i_blkbits matches the folio
+			 * size but the underlying filesystem or block device
+			 * uses a smaller granularity for IO.
 			 */
-			if (*bytes_submitted == folio_len)
+			if (*bytes_submitted == folio_len || !ifs)
 				ctx->cur_folio = NULL;
 		}
 
-- 
2.52.0

Re: [PATCH v1] iomap: fix invalid folio access when i_blkbits differs from I/O granularity

[Joanne Koong]

On Tue, Mar 17, 2026 at 1:47 PM Joanne Koong <joannelkoong@gmail.com> wrote:
>
> Commit aa35dd5cbc06 ("iomap: fix invalid folio access after
> folio_end_read()") partially addressed invalid folio access for folios
> without an ifs attached, but it did not handle the case where
> 1 << inode->i_blkbits matches the folio size but is different from the
> granularity used for the IO, which means IO can be submitted for less
> than the full folio for the !ifs case.
>
> In this case, the condition:
>
>   if (*bytes_submitted == folio_len)
>     ctx->cur_folio = NULL;
>
> in iomap_read_folio_iter() will not invalidate ctx->cur_folio, and
> iomap_read_end() will still be called on the folio even though the IO
> helper owns it and will finish the read on it.
>
> Fix this by unconditionally invalidating ctx->cur_folio for the !ifs
> case.
>
> Reported-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
> Tested-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
> Link: https://lore.kernel.org/linux-fsdevel/b3dfe271-4e3d-4922-b618-e73731242bca@wdc.com/
> Fixes: b2f35ac4146d ("iomap: add caller-provided callbacks for read and readahead")
> Cc: stable@vger.kernel.org
> Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
> ---
>  fs/iomap/buffered-io.c | 15 ++++++++++-----
>  1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
> index 3cf93ab2e38a..e4b6886e5c3c 100644
> --- a/fs/iomap/buffered-io.c
> +++ b/fs/iomap/buffered-io.c
> @@ -514,6 +514,7 @@ static int iomap_read_folio_iter(struct iomap_iter *iter,
>         loff_t length = iomap_length(iter);
>         struct folio *folio = ctx->cur_folio;
>         size_t folio_len = folio_size(folio);
> +       struct iomap_folio_state *ifs;
>         size_t poff, plen;
>         loff_t pos_diff;
>         int ret;
> @@ -525,7 +526,7 @@ static int iomap_read_folio_iter(struct iomap_iter *iter,
>                 return iomap_iter_advance(iter, length);
>         }
>
> -       ifs_alloc(iter->inode, folio, iter->flags);
> +       ifs = ifs_alloc(iter->inode, folio, iter->flags);
>
>         length = min_t(loff_t, length, folio_len - offset_in_folio(folio, pos));
>         while (length) {
> @@ -560,11 +561,15 @@ static int iomap_read_folio_iter(struct iomap_iter *iter,
>
>                         *bytes_submitted += plen;
>                         /*
> -                        * If the entire folio has been read in by the IO
> -                        * helper, then the helper owns the folio and will end
> -                        * the read on it.
> +                        * Hand off folio ownership to the IO helper when:
> +                        * 1) The entire folio has been submitted for IO, or
> +                        * 2) There is no ifs attached to the folio
> +                        *
> +                        * Case (2) occurs when 1 << i_blkbits matches the folio
> +                        * size but the underlying filesystem or block device
> +                        * uses a smaller granularity for IO.
>                          */
> -                       if (*bytes_submitted == folio_len)
> +                       if (*bytes_submitted == folio_len || !ifs)
>                                 ctx->cur_folio = NULL;
>                 }
>
> --
> 2.52.0
>

Forgot to add 'linux-fsdevel@vger.kernel.org' to the cc list, adding that now

Re: [PATCH v1] iomap: fix invalid folio access when i_blkbits differs from I/O granularity

[Christoph Hellwig]

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

Re: [PATCH v1] iomap: fix invalid folio access when i_blkbits differs from I/O granularity

[Christian Brauner]

On Tue, 17 Mar 2026 13:39:35 -0700, Joanne Koong wrote:
> Commit aa35dd5cbc06 ("iomap: fix invalid folio access after
> folio_end_read()") partially addressed invalid folio access for folios
> without an ifs attached, but it did not handle the case where
> 1 << inode->i_blkbits matches the folio size but is different from the
> granularity used for the IO, which means IO can be submitted for less
> than the full folio for the !ifs case.
> 
> [...]

Applied to the vfs.fixes branch of the vfs/vfs.git tree.
Patches in the vfs.fixes 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.fixes

[1/1] iomap: fix invalid folio access when i_blkbits differs from I/O granularity
      https://git.kernel.org/vfs/vfs/c/bd71fb3fea99