On Sun, Apr 30, 2023 at 08:14:03PM -0700, Luis Chamberlain wrote:
> On Sat, Apr 29, 2023 at 02:20:17AM +0100, Matthew Wilcox wrote:
> > > [ 11.322212] Call Trace:
> > > [ 11.323224] <TASK>
> > > [ 11.324146] iomap_readpage_iter+0x96/0x300
> > > [ 11.325694] iomap_readahead+0x174/0x2d0
> > > [ 11.327129] read_pages+0x69/0x1f0
> > > [ 11.329751] page_cache_ra_unbounded+0x187/0x1d0
> >
> > ... that shouldn't be possible. read_pages() allocates pages, puts them
> > in the page cache and tells the filesystem to fill them in.
> >
> > In your patches, did you call mapping_set_large_folios() anywhere?
>
> No but the only place to add that would be in the block cache. Adding
> that alone to the block cache doesn't fix the issue. The below patch
> however does get us by.
That's "working around the error", not fixing it ... probably the same
root cause as your other errors; at least I'm not diving into them until
the obvious one is fixed.
> >From my readings it does't seem like readahead_folio() should always
> return non-NULL, and also I couldn't easily verify the math is right.
readahead_folio() always returns non-NULL. That's guaranteed by how
page_cache_ra_unbounded() and page_cache_ra_order() work. It allocates
folios, until it can't (already-present folio, ENOMEM, EOF, max batch
size) and then calls the filesystem to make those folios uptodate,
telling it how many folios it put in the page cache, where they start.
Hm. The fact that it's coming from page_cache_ra_unbounded() makes
me wonder if you updated this line:
folio = filemap_alloc_folio(gfp_mask, 0);
without updating this line:
ractl->_nr_pages++;
This is actually number of pages, not number of folios, so needs to be
ractl->_nr_pages += 1 << order;
various other parts of page_cache_ra_unbounded() need to be examined
carefully for assumptions of order-0; it's never been used for that
before. all the large folio work has concentrated on
page_cache_ra_order()
