Re: [PATCH v1 2/2] fuse: use iomap helpers to update folio uptodate state

Matthew Wilcox <[email protected]> Wed, 24 Jun 2026 04:29:54 +0100
Newsgroups dev.linux.lists.fuse-devel,org.kernel.vger.linux-fsdevel
Message-ID <[email protected]>
On Tue, Jun 23, 2026 at 01:28:42PM -0700, Joanne Koong wrote:
> +++ b/fs/fuse/file.c
> @@ -1250,13 +1250,13 @@ static ssize_t fuse_send_write_pages(struct fuse_io_args *ia,
>  		struct folio *folio = ap->folios[i];
>  
>  		if (err) {
> -			folio_clear_uptodate(folio);
> +			iomap_folio_clear_uptodate(folio);
>  		} else {
>  			if (count >= folio_size(folio) - offset)
>  				count -= folio_size(folio) - offset;
>  			else {
>  				if (short_write)
> -					folio_clear_uptodate(folio);
> +					iomap_folio_clear_uptodate(folio);
>  				count = 0;

I believe this to be a bug.  I talked about this a bit as LSFMM, but the
fundamental problem is that the folio uptodate flag DOES NOT BELONG TO THE
FILESYSTEM (unlike the buffer_head uptodate flag, which definitely does).

The MM has a number of sanity checks that make sure we haven't
done something awful like mapping a !uptodate folio into userspace.
That would potentially leak confidential information to userspace.
So when a filesystem clears the uptodate flag, the MM can come along
and bring down the whole machine because the mapped folio is now !uptodate.

I know we have a terrible writeback error handling story.  But I think
the right thing to do is just take out the calls to clear uptodate.
In all filesystems.  Darrick took it out of iomap in e9c3a8e820ed but
it's time to purge it everywhere.