summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
diff options
context:
space:
mode:
authorDarrick J. Wong <djwong@kernel.org>2025-10-21 11:30:43 -0700
committerCarlos Maiolino <cem@kernel.org>2025-10-22 10:04:39 +0200
commitf477af0cfa0487eddec66ffe10fd9df628ba6f52 (patch)
treee6fefcdf7cc4e7a2909c1e75d6a5ea481c24e875 /drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
parent3e7ec343f066cb3b6916239680ab6ad44537b453 (diff)
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>
Diffstat (limited to 'drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c')
0 files changed, 0 insertions, 0 deletions