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: <20260205184620.1682986-1-clm@meta.com>
Date: Thu, 5 Feb 2026 10:44:40 -0800
From: Chris Mason <clm@...a.com>
To: "Darrick J. Wong" <djwong@...nel.org>
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

"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?

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