Re: Hang in generic/648 on zoned btrfs after aa35dd5cbc06 ("iomap: fix invalid folio access after folio_end_read()")

["Darrick J. Wong" <djwong@kernel.org>]

On Tue, Mar 10, 2026 at 02:08:28PM -0700, Joanne Koong wrote:
> On Tue, Mar 10, 2026 at 4:44 AM Johannes Thumshirn
> <Johannes.Thumshirn@wdc.com> wrote:
> >
> >
> > >
> > > 3. If you're able to repro this consistently, would you be able to add
> > > these lines right above the WARN_ON on line 487 and sharing what it
> > > prints out?
> > >
> > > +++ b/fs/iomap/buffered-io.c
> > > @@ -484,6 +484,17 @@ static void iomap_read_end(struct folio *folio,
> > > size_t bytes_submitted)
> > >                   * to the IO helper, in which case we are responsible for
> > >                   * unlocking the folio here.
> > >                   */
> > > +               if (bytes_submitted) {
> > > +                       struct inode *inode = folio->mapping->host;
> > > +                       struct block_device *bdev = inode->i_sb->s_bdev;
> > > +
> > > +                       pr_warn("bytes_submitted=%zu folio_size=%zu
> > > blkbits=%u isize=%lld "
> > > +                               "logical_bs=%u physical_bs=%u\n",
> > > +                               bytes_submitted, folio_size(folio),
> > > inode->i_blkbits,
> > > +                               i_size_read(inode),
> > > +                               bdev ? bdev_logical_block_size(bdev) : 0,
> > > +                               bdev ? bdev_physical_block_size(bdev) : 0);
> > > +               }
> > >                  WARN_ON_ONCE(bytes_submitted);
> > >                  folio_unlock(folio);
> > >          }
> >
> > Here we go:
> >
> > [   17.872952] bytes_submitted=1024 folio_size=4096 blkbits=12
> > isize=5278880768 logical_bs=0 physical_bs=0
> 
> Thank you, this is very helpful.
> 
> Is it correct that the block device's inode->i_blkbits doesn't reflect
> its actual logical block size (512) or is that itself a bug somewhere
> in the block layer?

For a bdev, i_blkbits is only loosely tied to the storage device's block
size.  i_blkbits can't be smaller than log2(lba_size) and it can't be
larger than PAGE_SHIFT (or the max folio order if LBS is present).

Typically it starts out matching PAGE_SIZE, but a program that opens the
block device can call BLKBSZSET to set the block size.  This is usually
done by userspace filesystem tools to improve performance and/or ensure
that the kernel actually supports that block size.

Note that kernel filesystem drivers also call sb_set_blocksize to set
the block size.

The bdev block size seemingly resets to 4k after closing.

> On the iomap side, it uses inode->i_blkbits to
> determine whether or not an ifs should be attached and what logic to
> correspondingly call. For this case, shouldn't the inode's i_blkbits
> be 9 since "isize= 5278880768" indicates it's 512-byte aligned, not
> 4096-byte aligned? I'm not familiar with the block layer, so your
> thoughts on this would be appreciated.

<shrug> Regular files can have a larger i_blkbits than the underlying
storage device, so I don't see why bdevs would be different?

--D

> If it is fine for the block device's inode->i_blkbits to be a
> different value from the logical block size, then I think the iomap
> side needs this fix:
> 
> diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
> index 867e8ac761c8..03a97361570f 100644
> --- a/fs/iomap/buffered-io.c
> +++ b/fs/iomap/buffered-io.c
> @@ -543,7 +543,7 @@ static int iomap_read_folio_iter(struct iomap_iter *iter,
>                          * helper, then the helper owns the folio and will end
>                          * the read on it.
>                          */
> -                       if (*bytes_submitted == folio_len)
> +                       if (*bytes_submitted == folio_len || !ifs)
>                                 ctx->cur_folio = NULL;
>                 }
> 
> Could you verify that this fixes the hang?
> 
> Thanks,
> Joanne
> >
>