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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260206043804.GL7686@frogsfrogsfrogs>
Date: Thu, 5 Feb 2026 20:38:04 -0800
From: "Darrick J. Wong" <djwong@...nel.org>
To: Chris Mason <clm@...a.com>
Cc: miklos@...redi.hu, joannelkoong@...il.com, bernd@...ernd.com,
	neal@...pa.dev, linux-ext4@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 05/10] fuse: invalidate iomap cache after file updates

On Thu, Feb 05, 2026 at 10:44:40AM -0800, Chris Mason wrote:
> "Darrick J. Wong" <djwong@...nel.org> wrote:
> > From: Darrick J. Wong <djwong@...nel.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@...nel.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);
> 
>