Re: Re: [PATCH v2] fuse: honor desc offset in readahead reads

[Joanne Koong]

On Fri, Jul 17, 2026 at 3:17 AM Horst Birthelmer <horst@xxxxxxxxxxxxx> wrote:
>
> On Fri, Jul 17, 2026 at 10:56:20AM +0200, Miklos Szeredi wrote:
> > On Fri, 17 Jul 2026 at 05:28, Haofeng Li <lihaofeng@xxxxxxxxxx> wrote:
> > >
> > > fuse_handle_readahead records non-zero descs[].offset when
> > > iomap skips leading uptodate blocks in a folio, but
> > > fuse_send_readpages built FUSE_READ from folio_pos() alone.
> > > The reply was still copied at descs[0].offset, so wrong
> > > file data was placed into the page cache.
> > >
> > > Add descs[0].offset to the request position. Apply the
> > > same correction in fuse_short_read for EOF size updates.
> > >
> > > Fixes: 4ea907108a5c ("fuse: use iomap for readahead")
> > > Signed-off-by: Haofeng Li <lihaofeng@xxxxxxxxxx>
> > > Reviewed-by: Joanne Koong <joannelkoong@xxxxxxxxx>
> >
> > Sashiko founds some more cases:
> > https://sashiko.dev/#/patchset/20260717032835.922433-1-lihaofeng%40kylinos.cn
> >
> > This is a large folio issue, right?  I do wonder why fsx-linux missed

What is fsx-linux?

> > these with the large folios enabled.
>
> I think it probably never occured since fuse_readahead() only fills in folio boundaries?
> This could be coincidence or readahead controls 'job'. I'm not that familiar with that code.
>
> I just got suspicious on your question, since I have large folios enabled in testing, too, and
> have not seen the case.
>

Looking more at this, I don't think this problem is actually
reachable. Haofeng, can you describe how you hit this issue?

This situation is only reached if there are prior uptodate blocks in
the folio. But looking at the filemap_get_pages() code in
mm/filemap.c, readahead is only called when handling first time reads
or speculatively prefetching new folios. afaict, there's no situation
where readahead gets called on a folio already in the page cache.

Thanks,
Joanne