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: <91881ad9-62c0-48c1-9cfd-e6cba6ddb587@meta.com>
Date: Thu, 5 Feb 2026 21:52:29 -0500
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 12/31] fuse: implement direct IO with iomap

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.

[ ... ]

>>> +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.

-chris