Re: [PATCH 16/17] block: use iomap for writes to block devices

From: Matthew Wilcox
Date: Wed May 24 2023 - 09:33:30 EST


On Wed, May 24, 2023 at 08:27:13AM +1000, Dave Chinner wrote:
> On Fri, May 19, 2023 at 04:22:01PM +0200, Hannes Reinecke wrote:
> > I'm hitting this during booting:
> > [ 5.016324] <TASK>
> > [ 5.030256] iomap_iter+0x11a/0x350
> > [ 5.030264] iomap_readahead+0x1eb/0x2c0
> > [ 5.030272] read_pages+0x5d/0x220
> > [ 5.030279] page_cache_ra_unbounded+0x131/0x180
> > [ 5.030284] filemap_get_pages+0xff/0x5a0
>
> Why is filemap_get_pages() using unbounded readahead? Surely
> readahead should be limited to reading within EOF....

It isn't using unbounded readahead; that's an artifact of this
incomplete stack trace. Actual call stack:

page_cache_ra_unbounded
do_page_cache_ra
ondemand_readahead
page_cache_sync_ra
page_cache_sync_readahead
filemap_get_pages

As you can see, do_page_cache_ra() does limit readahead to i_size.
Is ractl->mapping->host the correct way to find the inode? I always
get confused.

> I think Christoph's code is correct. IMO, any attempt to read beyond
> the end of the device should throw out a warning and return an
> error, not silently return zeros.
>
> If readahead is trying to read beyond the end of the device, then it
> really seems to me like the problem here is readahead, not the iomap
> code detecting the OOB read request....
>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@xxxxxxxxxxxxx