linux-ext4 - Re: [PATCH 14/31] fuse: implement buffered IO with iomap

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: <20260205191253.2011999-1-clm@meta.com>
Date: Thu, 5 Feb 2026 11:12:09 -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 14/31] fuse: implement buffered IO with iomap

"Darrick J. Wong" <djwong@...nel.org> wrote:
> From: Darrick J. Wong <djwong@...nel.org>
> 
> Implement pagecache IO with iomap, complete with hooks into truncate and
> fallocate so that the fuse server needn't implement disk block zeroing
> of post-EOF and unaligned punch/zero regions.
> 

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 05d561a4dd38273cb93745e8ddf913f490f81ad5
Author: Darrick J. Wong <djwong@...nel.org>

fuse: implement buffered IO with iomap

Implement pagecache IO with iomap, complete with hooks into truncate and
fallocate so that the fuse server needn't implement disk block zeroing
of post-EOF and unaligned punch/zero regions.

> diff --git a/fs/fuse/fuse_iomap.c b/fs/fuse/fuse_iomap.c

[ ... ]

> @@ -1056,6 +1144,365 @@ void fuse_iomap_open_truncate(struct inode *inode)
>  	fi->i_disk_size = 0;
>  }
>
> +struct fuse_writepage_ctx {
> +	struct iomap_writepage_ctx ctx;
> +};
> +
> +static void fuse_iomap_end_ioend(struct iomap_ioend *ioend)
> +{
> +	struct inode *inode = ioend->io_inode;
> +	unsigned int ioendflags = FUSE_IOMAP_IOEND_WRITEBACK;
> +	unsigned int nofs_flag;
> +	int error = blk_status_to_errno(ioend->io_bio.bi_status);
> +
> +	ASSERT(fuse_inode_has_iomap(inode));
> +
> +	if (fuse_is_bad(inode))
> +		return;
>                 ^^^^

Does this early return leak the ioend?  When fuse_is_bad(inode) returns
true, this function returns without calling iomap_finish_ioends().

Looking at the iomap code, iomap_finish_ioends() is responsible for:

1. Calling bio_put() to free the bio structure embedded in the ioend
2. Calling iomap_finish_folio_write() to end writeback on the folios

Without this cleanup, we get two problems:

- Memory leak: the bio structure is never freed
- Folios stuck in writeback state forever, which can cause system
  hangs as pages cannot be reclaimed or written again

The cleanup at line 1176 appears mandatory regardless of inode state.

[ ... ]