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: <20260206021440.GG7686@frogsfrogsfrogs>
Date: Thu, 5 Feb 2026 18:14:40 -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 14/31] fuse: implement buffered IO with iomap

On Thu, Feb 05, 2026 at 11:12:09AM -0800, Chris Mason wrote:
> "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.

Correct, will fix.

--D

> 
> [ ... ]
> 
>