From: Jiwei Sun <sunjw10@xxxxxxxxxx>
If the following configuration is set
CONFIG_LOCKDEP=y
The following warning log appears,
======================================================
WARNING: possible circular locking dependency detected
6.10.0-rc4-dirty #81 Not tainted
------------------------------------------------------
kswapd1/1465 is trying to acquire lock:
ff11000928da0160 (&xfs_nondir_ilock_class){++++}-{4:4}, at: xfs_icwalk_ag+0x7cd/0x14c0 [xfs]
but task is already holding lock:
ffffffff9fd44100 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat+0x856/0x11a0
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (fs_reclaim){+.+.}-{0:0}:
lock_acquire+0x194/0x490
fs_reclaim_acquire+0x103/0x160
__kmalloc_noprof+0x9b/0x430
xfs_attr_shortform_list+0x56a/0x15d0 [xfs]
xfs_attr_list+0x1cb/0x250 [xfs]
xfs_vn_listxattr+0xee/0x170 [xfs]
listxattr+0x5b/0xf0
__x64_sys_flistxattr+0x126/0x1b0
do_syscall_64+0x8a/0x170
entry_SYSCALL_64_after_hwframe+0x76/0x7e
-> #0 (&xfs_nondir_ilock_class){++++}-{4:4}:
validate_chain+0x171c/0x3270
__lock_acquire+0xecd/0x1ed0
lock_acquire+0x194/0x490
down_write_nested+0xa2/0x510
xfs_icwalk_ag+0x7cd/0x14c0 [xfs]
xfs_icwalk+0x4f/0xd0 [xfs]
xfs_reclaim_inodes_nr+0x144/0x1f0 [xfs]
super_cache_scan+0x305/0x430
do_shrink_slab+0x2f3/0xce0
shrink_slab+0x507/0xcb0
shrink_one+0x400/0x6d0
shrink_many+0x2d5/0xc10
shrink_node+0x1a0b/0x2110
balance_pgdat+0x7a2/0x11a0
kswapd+0x518/0x9c0
kthread+0x2e9/0x3d0
ret_from_fork+0x2d/0x60
ret_from_fork_asm+0x1a/0x30
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(fs_reclaim);
lock(&xfs_nondir_ilock_class);
lock(fs_reclaim);
lock(&xfs_nondir_ilock_class);
*** DEADLOCK ***
2 locks held by kswapd1/1465:
#0: ffffffff9fd44100 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat+0x856/0x11a0
#1: ff110001d1dec0e8 (&type->s_umount_key#62){++++}-{4:4}, at: super_trylock_shared+0x18/0xa0
stack backtrace:
CPU: 182 PID: 1465 Comm: kswapd1 Kdump: loaded Not tainted 6.10.0-rc4-dirty #81 d8f3b21024b789e635a9c2daea46fdb7762f1b50
Hardware name: Lenovo ThinkServer SR660 V3/SR660 V3, BIOS T8E166X-2.54 05/30/2024
Call Trace:
<TASK>
dump_stack_lvl+0x7c/0xc0
check_noncircular+0x31f/0x3f0
validate_chain+0x171c/0x3270
__lock_acquire+0xecd/0x1ed0
lock_acquire+0x194/0x490
down_write_nested+0xa2/0x510
xfs_icwalk_ag+0x7cd/0x14c0 [xfs 681f3433bed0d714083e513d149a819b095e6e51]
xfs_icwalk+0x4f/0xd0 [xfs 681f3433bed0d714083e513d149a819b095e6e51]
xfs_reclaim_inodes_nr+0x144/0x1f0 [xfs 681f3433bed0d714083e513d149a819b095e6e51]
super_cache_scan+0x305/0x430
do_shrink_slab+0x2f3/0xce0
shrink_slab+0x507/0xcb0
shrink_one+0x400/0x6d0
shrink_many+0x2d5/0xc10
shrink_node+0x1a0b/0x2110
balance_pgdat+0x7a2/0x11a0
kswapd+0x518/0x9c0
kthread+0x2e9/0x3d0
ret_from_fork+0x2d/0x60
ret_from_fork_asm+0x1a/0x30
</TASK>
This is a false positive. If a node is getting reclaimed, it cannot be
the target of a flistxattr operation. Commit 6dcde60efd94 ("xfs: more
lockdep whackamole with kmem_alloc*") has the similar root cause.
Fix the issue by adding __GFP_NOLOCKDEP in order to shut up lockdep.
Signed-off-by: Jiwei Sun <sunjw10@xxxxxxxxxx>
Suggested-by: Adrian Huang <ahuang12@xxxxxxxxxx>
---
fs/xfs/xfs_attr_list.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/xfs/xfs_attr_list.c b/fs/xfs/xfs_attr_list.c
index 5c947e5ce8b8..506ade0befa4 100644
--- a/fs/xfs/xfs_attr_list.c
+++ b/fs/xfs/xfs_attr_list.c
@@ -114,7 +114,8 @@ xfs_attr_shortform_list(
* It didn't all fit, so we have to sort everything on hashval.
*/
sbsize = sf->count * sizeof(*sbuf);
- sbp = sbuf = kmalloc(sbsize, GFP_KERNEL | __GFP_NOFAIL);
+ sbp = sbuf = kmalloc(sbsize, GFP_KERNEL | __GFP_NOFAIL |
+ __GFP_NOLOCKDEP);
/*
* Scan the attribute list for the rest of the entries, storing
--
2.27.0
