linux-kernel - Re: [PATCH] xfs: mark the i_delayed_blks access in xfs_file

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: <20250514130417.GA21064@lst.de>
Date: Wed, 14 May 2025 15:04:17 +0200
From: Christoph Hellwig <hch@....de>
To: Carlos Maiolino <cem@...nel.org>
Cc: Christoph Hellwig <hch@....de>, Dave Chinner <david@...morbit.com>,
	linux-xfs@...r.kernel.org, cen zhang <zzzccc427@...il.com>,
	lkmm@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] xfs: mark the i_delayed_blks access in
 xfs_file_release as racy

On Wed, May 14, 2025 at 10:00:28AM +0200, Carlos Maiolino wrote:
> I agree with you here, and we could slowly start marking those shared accesses
> as racy, but bots spitting false-positivies all the time doesn't help much,
> other than taking somebody's else time to look into the report.
> 
> Taking as example one case in the previous report, where the report complained
> about concurrent bp->b_addr access during the buffer instantiation.

I'd like to understand that one a bit more.  It might be because the
validator doesn't understand a semaphore used as lock is a lock, but
I'll follow up there.

> So, I think Dave has a point too. Like what happens with syzkaller
> and random people reporting random syzkaller warnings.
> 
> While I appreciate the reports too, I think it would be fair for the reporters
> to spend some time to at least craft a RFC patch fixing the warning.

Well, it was polite mails about their finding, which I find useful.
If we got a huge amount of spam that might be different.