Re: [PATCH 05/10] fuse: invalidate iomap cache after file updates

["Darrick J. Wong" <djwong@kernel.org>]

On Thu, Feb 05, 2026 at 10:44:40AM -0800, Chris Mason wrote:
> "Darrick J. Wong" <djwong@kernel.org> wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> > 
> > The kernel doesn't know what the fuse server might have done in response
> > to truncate, fallocate, or ioend events.  Therefore, it must invalidate
> > the mapping cache after those operations to ensure cache coherency.
> > 
> 
> Hi everyone,
> 
> I'm trying out my AI review prompts on a few more trees, and I ran it
> on the fuse-iomap-cache branch:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=fuse-iomap-cache
> 
> This was the latest email lore could find, apologies if I grabbed the wrong one.
> 
> Hopefully the review below is useful, please let me know if there are places it
> has gone wildly wrong.  I kept the header to make it obvious exactly which
> commit I'd run through:
> 
> commit 8cd55ddf79a7cd6b1c8afbe08b72d8896da67306
> Author: Darrick J. Wong <djwong@kernel.org>
> 
> fuse: invalidate iomap cache after file updates
> 
> This commit fixes a cache coherency bug by adding cache invalidation
> calls after file-modifying operations to prevent stale cached iomap
> entries from being used.
> 
> > diff --git a/fs/fuse/file.c b/fs/fuse/file.c
> > --- a/fs/fuse/file.c
> > +++ b/fs/fuse/file.c
> 
> [ ... ]
> 
> > @@ -3202,7 +3205,9 @@ struct fuse_copy_file_range_in inarg = {
> >  		goto out;
> >  	}
> >
> > -	if (!is_iomap)
> > +	if (is_iomap)
> > +		fuse_iomap_copied_file_range(inode_out, pos_out, outarg.size);
> 
> In __fuse_copy_file_range(), does this code pass the correct value to
> fuse_iomap_copied_file_range()?
> 
> When using the FUSE_COPY_FILE_RANGE_64 API (fc->no_copy_file_range_64
> is false), the response goes into 'outarg_64', not 'outarg'. The
> 'outarg' struct remains uninitialized in this path.
> 
> Looking at the code earlier in the function:
> 
>     if (fc->no_copy_file_range_64) {
>         args.out_args[0].size = sizeof(outarg);
>         args.out_args[0].value = &outarg;
>     } else {
>         args.out_args[0].size = sizeof(outarg_64);
>         args.out_args[0].value = &outarg_64;
>     }
> 
>     /* ... */
> 
>     if (args.out_args[0].value == &outarg_64)
>         bytes_copied = outarg_64.size;
>     else
>         bytes_copied = outarg.size;
> 
> The 'bytes_copied' variable correctly handles both API versions. The
> else branch (non-iomap path) already uses 'bytes_copied' for
> truncate_inode_pages_range().
> 
> When the 64-bit API succeeds, could the cache invalidation use
> garbage/zero data for the range instead of the actual bytes copied,
> potentially leaving stale mappings in the cache?

Yes, fuse_iomap_copied_file_range should have its @written parameter
changed to u64.  I forgot to make that amendment after
FUSE_COPY_FILE_RANGE_64 was introduced last cycle.  It is a very good
sign that your AI prompts can catch bitrot during development!

--D

> 
> > +	else
> >  		truncate_inode_pages_range(inode_out->i_mapping,
> >  				   ALIGN_DOWN(pos_out, PAGE_SIZE),
> >  				   ALIGN(pos_out + bytes_copied, PAGE_SIZE) - 1);
> 
>