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

Joanne Koong <[email protected]> Thu, 16 Jul 2026 11:11:10 -0700
Newsgroups dev.linux.lists.fuse-devel,org.kernel.vger.linux-kernel
Message-ID <CAJnrk1ZDc=f1XvRU6j6WsqiSAy75wd1-X2fNRhcK3j-OGDkqcw@mail.gmail.com>
On Thu, Jul 16, 2026 at 2:41=E2=80=AFAM Haofeng Li <[email protected]> w=
rote:
>
> 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]>
> ---
>  fs/fuse/file.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/fs/fuse/file.c b/fs/fuse/file.c
> index ceada75310b8..11272983c991 100644
> --- a/fs/fuse/file.c
> +++ b/fs/fuse/file.c
> @@ -836,7 +836,8 @@ static void fuse_short_read(struct inode *inode, u64 =
attr_ver, size_t num_read,
>          * reached the client fs yet.  So the hole is not present there.
>          */
>         if (!fc->writeback_cache) {
> -               loff_t pos =3D folio_pos(ap->folios[0]) + num_read;
> +               loff_t pos =3D folio_pos(ap->folios[0]) +
> +                            ap->descs[0].offset + num_read;
>                 fuse_read_update_size(inode, pos, attr_ver);
>         }
>  }
> @@ -1057,7 +1058,8 @@ static void fuse_send_readpages(struct fuse_io_args=
 *ia, struct file *file,
>         struct fuse_file *ff =3D file->private_data;
>         struct fuse_mount *fm =3D ff->fm;
>         struct fuse_args_pages *ap =3D &ia->ap;
> -       loff_t pos =3D folio_pos(ap->folios[0]);
> +       loff_t pos =3D folio_pos(ap->folios[0]) +
> +                    ap->descs[0].offset;

nit: is this newline needed?

>         ssize_t res;
>         int err>

LGTM. Thanks for catching this.

Reviewed-by: Joanne Koong <[email protected]>