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

On Fri, Jul 17, 2026 at 3:17=E2=80=AFAM Horst Birthelmer <horst@birthelmer.=
de> wrote:
>
> On Fri, Jul 17, 2026 at 10:56:20AM +0200, Miklos Szeredi wrote:
> > On Fri, 17 Jul 2026 at 05:28, Haofeng Li <[email protected]> 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 <[email protected]>
> > > Reviewed-by: Joanne Koong <[email protected]>
> >
> > Sashiko founds some more cases:
> > https://sashiko.dev/#/patchset/20260717032835.922433-1-lihaofeng%40kyli=
nos.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 fo=
lio boundaries?
> This could be coincidence or readahead controls 'job'. I'm not that famil=
iar 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