linux-kernel - Re: [BUG] Data race between xfs_file_release and xfs_bmap_del_extent_delay about i_delayed

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] [day] [month] [year] [list]

Message-ID: <aCF6CEJoh3En3icU@infradead.org>
Date: Sun, 11 May 2025 21:33:12 -0700
From: Christoph Hellwig <hch@...radead.org>
To: cen zhang <zzzccc427@...il.com>
Cc: cem@...nel.org, linux-xfs@...r.kernel.org, linux-kernel@...r.kernel.org,
	baijiaju1990@...il.com, zhenghaoran154@...il.com
Subject: Re: [BUG] Data race between xfs_file_release and
 xfs_bmap_del_extent_delay about i_delayed_blks

On Mon, May 12, 2025 at 12:01:54PM +0800, cen zhang wrote:
> I would like to report a data race bug detected in
> the Btrfs filesystem on Linux kernel 6.14-rc4.

xfs?

> The issue was discovered by our tools,

As in KCSAN?

> Reader (fs/xfs/xfs_file.c):
> xfs_file_release  {
> ……
>         xfs_iflags_clear(ip, XFS_EOFBLOCKS_RELEASED);
>         if (ip->i_delayed_blks > 0)
>             filemap_flush(inode->i_mapping);
> ……
> }

And this should make it very clear that the race does not matter.
bu we should indeed throw in a data_race() and a comment to make that
clear.  I'll take care of that.