Darrick J. Wong 6dcde60efd xfs: more lockdep whackamole with kmem_alloc* ... Dave Airlie reported the following lockdep complaint: > ====================================================== > WARNING: possible circular locking dependency detected > 5.7.0-0.rc5.20200515git1ae7efb38854.1.fc33.x86_64 #1 Not tainted > ------------------------------------------------------ > kswapd0/159 is trying to acquire lock: > ffff9b38d01a4470 (&xfs_nondir_ilock_class){++++}-{3:3}, > at: xfs_ilock+0xde/0x2c0 [xfs] > > but task is already holding lock: > ffffffffbbb8bd00 (fs_reclaim){+.+.}-{0:0}, at: > __fs_reclaim_acquire+0x5/0x30 > > which lock already depends on the new lock. > > > the existing dependency chain (in reverse order) is: > > -> #1 (fs_reclaim){+.+.}-{0:0}: > fs_reclaim_acquire+0x34/0x40 > __kmalloc+0x4f/0x270 > kmem_alloc+0x93/0x1d0 [xfs] > kmem_alloc_large+0x4c/0x130 [xfs] > xfs_attr_copy_value+0x74/0xa0 [xfs] > xfs_attr_get+0x9d/0xc0 [xfs] > xfs_get_acl+0xb6/0x200 [xfs] > get_acl+0x81/0x160 > posix_acl_xattr_get+0x3f/0xd0 > vfs_getxattr+0x148/0x170 > getxattr+0xa7/0x240 > path_getxattr+0x52/0x80 > do_syscall_64+0x5c/0xa0 > entry_SYSCALL_64_after_hwframe+0x49/0xb3 > > -> #0 (&xfs_nondir_ilock_class){++++}-{3:3}: > __lock_acquire+0x1257/0x20d0 > lock_acquire+0xb0/0x310 > down_write_nested+0x49/0x120 > xfs_ilock+0xde/0x2c0 [xfs] > xfs_reclaim_inode+0x3f/0x400 [xfs] > xfs_reclaim_inodes_ag+0x20b/0x410 [xfs] > xfs_reclaim_inodes_nr+0x31/0x40 [xfs] > super_cache_scan+0x190/0x1e0 > do_shrink_slab+0x184/0x420 > shrink_slab+0x182/0x290 > shrink_node+0x174/0x680 > balance_pgdat+0x2d0/0x5f0 > kswapd+0x21f/0x510 > kthread+0x131/0x150 > ret_from_fork+0x3a/0x50 > > 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 *** > > 4 locks held by kswapd0/159: > #0: ffffffffbbb8bd00 (fs_reclaim){+.+.}-{0:0}, at: > __fs_reclaim_acquire+0x5/0x30 > #1: ffffffffbbb7cef8 (shrinker_rwsem){++++}-{3:3}, at: > shrink_slab+0x115/0x290 > #2: ffff9b39f07a50e8 > (&type->s_umount_key#56){++++}-{3:3}, at: super_cache_scan+0x38/0x1e0 > #3: ffff9b39f077f258 > (&pag->pag_ici_reclaim_lock){+.+.}-{3:3}, at: > xfs_reclaim_inodes_ag+0x82/0x410 [xfs] This is a known false positive because inodes cannot simultaneously be getting reclaimed and the target of a getxattr operation, but lockdep doesn't know that. We can (selectively) shut up lockdep until either it gets smarter or we change inode reclaim not to require the ILOCK by applying a stupid GFP_NOLOCKDEP bandaid. Reported-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Tested-by: Dave Airlie <airlied@gmail.com> Reviewed-by: Brian Foster <bfoster@redhat.com>		2020-05-27 08:49:28 -07:00
..
xfs_ag_resv.c
xfs_ag_resv.h
xfs_ag.c
xfs_ag.h
xfs_alloc_btree.c
xfs_alloc_btree.h
xfs_alloc.c
xfs_alloc.h
xfs_attr_leaf.c
xfs_attr_leaf.h
xfs_attr_remote.c
xfs_attr_remote.h
xfs_attr_sf.h
xfs_attr.c
xfs_attr.h
xfs_bit.c
xfs_bit.h
xfs_bmap_btree.c
xfs_bmap_btree.h
xfs_bmap.c
xfs_bmap.h
xfs_btree_staging.c
xfs_btree_staging.h
xfs_btree.c
xfs_btree.h
xfs_cksum.h
xfs_da_btree.c
xfs_da_btree.h
xfs_da_format.h
xfs_defer.c
xfs_defer.h
xfs_dir2_block.c
xfs_dir2_data.c
xfs_dir2_leaf.c
xfs_dir2_node.c
xfs_dir2_priv.h
xfs_dir2_sf.c
xfs_dir2.c
xfs_dir2.h
xfs_dquot_buf.c
xfs_errortag.h
xfs_format.h
xfs_fs.h
xfs_health.h
xfs_ialloc_btree.c
xfs_ialloc_btree.h
xfs_ialloc.c
xfs_ialloc.h
xfs_iext_tree.c
xfs_inode_buf.c
xfs_inode_buf.h
xfs_inode_fork.c
xfs_inode_fork.h
xfs_log_format.h
xfs_log_recover.h
xfs_log_rlimit.c
xfs_quota_defs.h
xfs_refcount_btree.c
xfs_refcount_btree.h
xfs_refcount.c
xfs_refcount.h
xfs_rmap_btree.c
xfs_rmap_btree.h
xfs_rmap.c
xfs_rmap.h
xfs_rtbitmap.c
xfs_sb.c
xfs_sb.h
xfs_shared.h
xfs_symlink_remote.c
xfs_trans_inode.c
xfs_trans_resv.c
xfs_trans_resv.h
xfs_trans_space.h
xfs_types.c
xfs_types.h