Josef Bacik
8807401c6f
btrfs: use nofs allocations for running delayed items ...
[ Upstream commit 351cbf6e4410e7ece05e35d0a07320538f2418b4 ]
Zygo reported the following lockdep splat while testing the balance
patches
======================================================
WARNING: possible circular locking dependency detected
5.6.0-c6f0579d496a+ #53 Not tainted
------------------------------------------------------
kswapd0/1133 is trying to acquire lock:
ffff888092f622c0 (&delayed_node->mutex){+.+.}, at: __btrfs_release_delayed_node+0x7c/0x5b0
but task is already holding lock:
ffffffff8fc5f860 (fs_reclaim){+.+.}, 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){+.+.}:
fs_reclaim_acquire.part.91+0x29/0x30
fs_reclaim_acquire+0x19/0x20
kmem_cache_alloc_trace+0x32/0x740
add_block_entry+0x45/0x260
btrfs_ref_tree_mod+0x6e2/0x8b0
btrfs_alloc_tree_block+0x789/0x880
alloc_tree_block_no_bg_flush+0xc6/0xf0
__btrfs_cow_block+0x270/0x940
btrfs_cow_block+0x1ba/0x3a0
btrfs_search_slot+0x999/0x1030
btrfs_insert_empty_items+0x81/0xe0
btrfs_insert_delayed_items+0x128/0x7d0
__btrfs_run_delayed_items+0xf4/0x2a0
btrfs_run_delayed_items+0x13/0x20
btrfs_commit_transaction+0x5cc/0x1390
insert_balance_item.isra.39+0x6b2/0x6e0
btrfs_balance+0x72d/0x18d0
btrfs_ioctl_balance+0x3de/0x4c0
btrfs_ioctl+0x30ab/0x44a0
ksys_ioctl+0xa1/0xe0
__x64_sys_ioctl+0x43/0x50
do_syscall_64+0x77/0x2c0
entry_SYSCALL_64_after_hwframe+0x49/0xbe
-> #0 (&delayed_node->mutex){+.+.}:
__lock_acquire+0x197e/0x2550
lock_acquire+0x103/0x220
__mutex_lock+0x13d/0xce0
mutex_lock_nested+0x1b/0x20
__btrfs_release_delayed_node+0x7c/0x5b0
btrfs_remove_delayed_node+0x49/0x50
btrfs_evict_inode+0x6fc/0x900
evict+0x19a/0x2c0
dispose_list+0xa0/0xe0
prune_icache_sb+0xbd/0xf0
super_cache_scan+0x1b5/0x250
do_shrink_slab+0x1f6/0x530
shrink_slab+0x32e/0x410
shrink_node+0x2a5/0xba0
balance_pgdat+0x4bd/0x8a0
kswapd+0x35a/0x800
kthread+0x1e9/0x210
ret_from_fork+0x3a/0x50
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(fs_reclaim);
lock(&delayed_node->mutex);
lock(fs_reclaim);
lock(&delayed_node->mutex);
*** DEADLOCK ***
3 locks held by kswapd0/1133:
#0 : ffffffff8fc5f860 (fs_reclaim){+.+.}, at: __fs_reclaim_acquire+0x5/0x30
#1 : ffffffff8fc380d8 (shrinker_rwsem){++++}, at: shrink_slab+0x1e8/0x410
#2 : ffff8881e0e6c0e8 (&type->s_umount_key#42){++++}, at: trylock_super+0x1b/0x70
stack backtrace:
CPU: 2 PID: 1133 Comm: kswapd0 Not tainted 5.6.0-c6f0579d496a+ #53
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
Call Trace:
dump_stack+0xc1/0x11a
print_circular_bug.isra.38.cold.57+0x145/0x14a
check_noncircular+0x2a9/0x2f0
? print_circular_bug.isra.38+0x130/0x130
? stack_trace_consume_entry+0x90/0x90
? save_trace+0x3cc/0x420
__lock_acquire+0x197e/0x2550
? btrfs_inode_clear_file_extent_range+0x9b/0xb0
? register_lock_class+0x960/0x960
lock_acquire+0x103/0x220
? __btrfs_release_delayed_node+0x7c/0x5b0
__mutex_lock+0x13d/0xce0
? __btrfs_release_delayed_node+0x7c/0x5b0
? __asan_loadN+0xf/0x20
? pvclock_clocksource_read+0xeb/0x190
? __btrfs_release_delayed_node+0x7c/0x5b0
? mutex_lock_io_nested+0xc20/0xc20
? __kasan_check_read+0x11/0x20
? check_chain_key+0x1e6/0x2e0
mutex_lock_nested+0x1b/0x20
? mutex_lock_nested+0x1b/0x20
__btrfs_release_delayed_node+0x7c/0x5b0
btrfs_remove_delayed_node+0x49/0x50
btrfs_evict_inode+0x6fc/0x900
? btrfs_setattr+0x840/0x840
? do_raw_spin_unlock+0xa8/0x140
evict+0x19a/0x2c0
dispose_list+0xa0/0xe0
prune_icache_sb+0xbd/0xf0
? invalidate_inodes+0x310/0x310
super_cache_scan+0x1b5/0x250
do_shrink_slab+0x1f6/0x530
shrink_slab+0x32e/0x410
? do_shrink_slab+0x530/0x530
? do_shrink_slab+0x530/0x530
? __kasan_check_read+0x11/0x20
? mem_cgroup_protected+0x13d/0x260
shrink_node+0x2a5/0xba0
balance_pgdat+0x4bd/0x8a0
? mem_cgroup_shrink_node+0x490/0x490
? _raw_spin_unlock_irq+0x27/0x40
? finish_task_switch+0xce/0x390
? rcu_read_lock_bh_held+0xb0/0xb0
kswapd+0x35a/0x800
? _raw_spin_unlock_irqrestore+0x4c/0x60
? balance_pgdat+0x8a0/0x8a0
? finish_wait+0x110/0x110
? __kasan_check_read+0x11/0x20
? __kthread_parkme+0xc6/0xe0
? balance_pgdat+0x8a0/0x8a0
kthread+0x1e9/0x210
? kthread_create_worker_on_cpu+0xc0/0xc0
ret_from_fork+0x3a/0x50
This is because we hold that delayed node's mutex while doing tree
operations. Fix this by just wrapping the searches in nofs.
CC: stable@vger.kernel.org # 4.4+
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-04-24 08:00:48 +02:00
2019-10-11 18:18:38 +02:00
2019-08-06 19:05:21 +02:00
2020-01-27 14:46:52 +01:00
2020-04-02 16:34:33 +02:00
2019-12-17 20:37:24 +01:00
2017-11-02 11:10:55 +01:00
2018-12-01 09:42:51 +01:00
2020-04-24 08:00:48 +02:00
2018-12-17 09:28:53 +01:00
2020-04-13 10:34:35 +02:00
2020-04-24 08:00:40 +02:00
2019-08-06 19:05:23 +02:00
2019-11-12 19:18:18 +01:00
2018-11-13 11:15:12 -08:00
2019-07-31 07:28:22 +02:00
2019-05-08 07:20:49 +02:00
2019-03-23 14:35:21 +01:00
2019-12-17 20:38:33 +01:00
2020-03-11 18:02:51 +01:00
2017-07-11 06:09:21 -04:00
2017-11-02 11:10:55 +01:00
2019-12-05 15:37:28 +01:00
2020-01-27 14:46:06 +01:00
2020-02-14 16:32:17 -05:00
2020-04-24 08:00:43 +02:00
2020-02-28 16:36:05 +01:00
2020-03-11 18:03:03 +01:00
2018-12-17 09:28:53 +01:00
2019-12-17 20:38:44 +01:00
2020-04-24 08:00:27 +02:00
2019-12-01 09:13:57 +01:00
2020-04-24 08:00:45 +02:00
2017-11-02 11:10:55 +01:00
2017-11-02 11:10:55 +01:00
2019-05-31 06:47:12 -07:00
2018-10-03 17:00:57 -07:00
2020-03-20 10:54:26 +01:00
2019-05-08 07:20:49 +02:00
2020-01-27 14:46:26 +01:00
2019-12-17 20:38:50 +01:00
2019-12-17 20:38:15 +01:00
2017-11-02 11:10:55 +01:00
2018-03-28 18:24:43 +02:00
2020-04-24 08:00:43 +02:00
2018-02-03 17:39:08 +01:00
2020-02-14 16:32:17 -05:00
2018-05-30 07:51:47 +02:00
2017-11-02 11:10:55 +01:00
2020-01-12 12:11:59 +01:00
2017-11-02 11:10:55 +01:00
2020-04-24 08:00:43 +02:00
2017-11-02 11:10:55 +01:00
2020-02-28 16:36:08 +01:00
2019-12-17 20:39:21 +01:00
2019-11-24 08:23:23 +01:00
2020-01-09 10:17:55 +01:00
2017-11-02 11:10:55 +01:00
2017-11-02 11:10:55 +01:00
2020-01-12 12:11:59 +01:00
2017-09-06 17:27:26 -07:00
2020-02-28 16:36:08 +01:00
2017-11-02 11:10:55 +01:00
2018-09-05 09:26:32 +02:00
2018-09-05 09:26:41 +02:00
2018-12-17 09:28:48 +01:00
2017-07-06 03:31:46 -04:00
2020-02-14 16:32:11 -05:00
2020-02-28 16:36:02 +01:00
2019-05-25 18:25:36 +02:00
2020-01-27 14:46:02 +01:00
2018-12-21 14:13:04 +01:00
2017-11-02 11:10:55 +01:00
2017-11-02 11:10:55 +01:00
2017-09-04 19:05:15 -04:00
2017-09-14 18:13:32 -07:00
2019-10-05 12:48:06 +02:00
2019-07-03 13:15:59 +02:00
2018-06-26 08:06:33 +08:00
2019-11-06 12:42:59 +01:00
2019-04-17 08:37:53 +02:00
2019-04-05 22:31:28 +02:00
2020-01-14 20:05:39 +01:00
2020-01-09 10:17:58 +01:00
2017-11-02 11:10:55 +01:00
2020-03-11 18:02:43 +01:00
2019-02-06 17:31:34 +01:00
2019-04-27 09:35:41 +02:00
2020-01-12 12:11:59 +01:00
2017-07-03 21:13:25 -07:00
2019-02-12 19:46:10 +01:00
2020-04-24 08:00:38 +02:00
2017-12-17 15:07:59 +01:00
2017-11-02 11:10:55 +01:00
2017-08-28 00:50:23 -04:00
2019-04-05 22:31:28 +02:00
2020-04-24 08:00:43 +02:00
2017-11-02 11:10:55 +01:00
2019-11-12 19:18:47 +01:00
2020-04-02 16:34:21 +02:00
2017-09-13 09:11:44 -07:00
2018-11-10 07:48:33 -08:00
2019-12-17 20:38:57 +01:00
2017-07-12 16:26:00 -07:00
2020-04-02 16:34:35 +02:00
2020-01-09 10:17:55 +01:00
2017-11-02 11:10:55 +01:00
2018-02-22 15:42:25 +01:00
2017-11-02 11:10:55 +01:00
2017-11-02 11:10:55 +01:00
2020-03-11 18:02:53 +01:00
2018-11-21 09:24:14 +01:00
2017-11-02 11:10:55 +01:00
2020-03-20 10:54:16 +01:00
2019-05-04 09:15:18 +02:00
2017-11-02 11:10:55 +01:00
2019-12-01 09:13:51 +01:00
2020-01-04 14:00:04 +01:00
2017-11-02 11:10:55 +01:00
2018-02-22 15:42:28 +01:00
2017-11-02 11:10:55 +01:00
2019-05-04 09:15:18 +02:00
2017-11-02 11:10:55 +01:00
2019-10-11 18:18:48 +02:00
2018-05-30 07:51:47 +02:00
2017-11-02 11:10:55 +01:00
2017-11-02 11:10:55 +01:00
2020-01-04 13:59:58 +01:00
2017-11-02 11:10:55 +01:00
2018-10-10 08:54:27 +02:00
8807401c6f