linux-ext4 - Re: [PATCH 12/31] fuse: implement direct 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: <20260206050823.GH1535390@frogsfrogsfrogs>
Date: Thu, 5 Feb 2026 21:08:23 -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 12/31] fuse: implement direct IO with iomap

On Thu, Feb 05, 2026 at 09:52:29PM -0500, Chris Mason wrote:
> On 2/5/26 9:08 PM, Darrick J. Wong wrote:
> > On Thu, Feb 05, 2026 at 11:19:11AM -0800, Chris Mason wrote:
> >> "Darrick J. Wong" <djwong@...nel.org> wrote:
> >>> From: Darrick J. Wong <djwong@...nel.org>
> >>>
> >>> Start implementing the fuse-iomap file I/O paths by adding direct I/O
> >>> support and all the signalling flags that come with it.  Buffered I/O
> >>> is much more complicated, so we leave that to a subsequent patch.
> >>>
> >>
> >> 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 
> > 
> > I should mention: I appreciate you rolling out the AI reviews by slowly
> > expanding the number of trees you scan for bugs.
> 
> Thanks, I'm trying not to send unsolicited AI unless it feels like it's
> mostly right.  I did discard one false positive, which looked accurate
> but also looked like intended behavior.
> 
> Now that the false positive rate is pretty reasonable, I'll try to
> collect some fs/* Fixes: tagged patches and see if I can teach claude
> how to spot the bugs.  In past kernel-wide scans, it gets ~35%, which is
> better than 0, but not as good as I was hoping for.

<nod> You've found some very good bugs, especially in the fuse-iomap
branch!  At some point I'm going to have to figure out how to run these
tools myself, but until then you're quite welcome to keep scanning my
dev trees. :)

I wonder, have you tried it on non-kernel repos like e2fsprogs (ha!) or
fstests?

> [ ... ]
> 
> >>> +static int fuse_iomap_ilock_iocb(const struct kiocb *iocb,
> >>> +				 enum fuse_ilock_type type)
> >>> +{
> >>> +	struct inode *inode = file_inode(iocb->ki_filp);
> >>> +
> >>> +	if (iocb->ki_flags & IOCB_NOWAIT) {
> >>> +		switch (type) {
> >>> +		case SHARED:
> >>> +			return inode_trylock_shared(inode) ? 0 : -EAGAIN;
> >>> +		case EXCL:
> >>> +			return inode_trylock(inode) ? 0 : -EAGAIN;
> >>> +		default:
> >>> +			ASSERT(0);
> >>> +			return -EIO;
> >>> +		}
> >>> +
> >>> +		return 0;
> >>> +	}
> >>
> >> This isn't a bug, but the 'return 0;' after the switch statement inside
> >> the IOCB_NOWAIT block is unreachable since every switch case returns.
> > 
> > gcc is too stupid to detect that it's impossible to reach this case and
> > whines about the lack of a return.
> 
> Oh that's great.

I know, right? :(

--D

> -chris
>