]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
xfs: fix locking in xchk_nlinks_collect_dir
authorDarrick J. Wong <djwong@kernel.org>
Tue, 21 Oct 2025 18:30:43 +0000 (11:30 -0700)
committerCarlos Maiolino <cem@kernel.org>
Wed, 22 Oct 2025 08:04:39 +0000 (10:04 +0200)
commitf477af0cfa0487eddec66ffe10fd9df628ba6f52
treee6fefcdf7cc4e7a2909c1e75d6a5ea481c24e875
parent3e7ec343f066cb3b6916239680ab6ad44537b453
xfs: fix locking in xchk_nlinks_collect_dir

On a filesystem with parent pointers, xchk_nlinks_collect_dir walks both
the directory entries (data fork) and the parent pointers (attr fork) to
determine the correct link count.  Unfortunately I forgot to update the
lock mode logic to handle the case of a directory whose attr fork is in
btree format and has not yet been loaded *and* whose data fork doesn't
need loading.

This leads to a bunch of assertions from xfs/286 in xfs_iread_extents
because we only took ILOCK_SHARED, not ILOCK_EXCL.  You'd need the rare
happenstance of a directory with a large number of non-pptr extended
attributes set and enough memory pressure to cause the directory to be
evicted and partially reloaded from disk.

I /think/ this only started in 6.18-rc1 because I've started seeing OOM
errors with the maple tree slab using 70% of memory, and this didn't
happen in 6.17.  Yay dynamic systems!

Cc: stable@vger.kernel.org # v6.10
Fixes: 77ede5f44b0d86 ("xfs: walk directory parent pointers to determine backref count")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
fs/xfs/scrub/nlinks.c