Josef Bacik
76c3819639
btrfs: sysfs: use NOFS for device creation ...
[ Upstream commit a47bd78d0c44621efb98b525d04d60dc4d1a79b0 ]
Dave hit this splat during testing btrfs/078:
======================================================
WARNING: possible circular locking dependency detected
5.8.0-rc6-default+ #1191 Not tainted
------------------------------------------------------
kswapd0/75 is trying to acquire lock:
ffffa040e9d04ff8 (&delayed_node->mutex){+.+.}-{3:3}, at: __btrfs_release_delayed_node.part.0+0x3f/0x310 [btrfs]
but task is already holding lock:
ffffffff8b0c8040 (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:
-> #2 (fs_reclaim){+.+.}-{0:0}:
__lock_acquire+0x56f/0xaa0
lock_acquire+0xa3/0x440
fs_reclaim_acquire.part.0+0x25/0x30
__kmalloc_track_caller+0x49/0x330
kstrdup+0x2e/0x60
__kernfs_new_node.constprop.0+0x44/0x250
kernfs_new_node+0x25/0x50
kernfs_create_link+0x34/0xa0
sysfs_do_create_link_sd+0x5e/0xd0
btrfs_sysfs_add_devices_dir+0x65/0x100 [btrfs]
btrfs_init_new_device+0x44c/0x12b0 [btrfs]
btrfs_ioctl+0xc3c/0x25c0 [btrfs]
ksys_ioctl+0x68/0xa0
__x64_sys_ioctl+0x16/0x20
do_syscall_64+0x50/0xe0
entry_SYSCALL_64_after_hwframe+0x44/0xa9
-> #1 (&fs_info->chunk_mutex){+.+.}-{3:3}:
__lock_acquire+0x56f/0xaa0
lock_acquire+0xa3/0x440
__mutex_lock+0xa0/0xaf0
btrfs_chunk_alloc+0x137/0x3e0 [btrfs]
find_free_extent+0xb44/0xfb0 [btrfs]
btrfs_reserve_extent+0x9b/0x180 [btrfs]
btrfs_alloc_tree_block+0xc1/0x350 [btrfs]
alloc_tree_block_no_bg_flush+0x4a/0x60 [btrfs]
__btrfs_cow_block+0x143/0x7a0 [btrfs]
btrfs_cow_block+0x15f/0x310 [btrfs]
push_leaf_right+0x150/0x240 [btrfs]
split_leaf+0x3cd/0x6d0 [btrfs]
btrfs_search_slot+0xd14/0xf70 [btrfs]
btrfs_insert_empty_items+0x64/0xc0 [btrfs]
__btrfs_commit_inode_delayed_items+0xb2/0x840 [btrfs]
btrfs_async_run_delayed_root+0x10e/0x1d0 [btrfs]
btrfs_work_helper+0x2f9/0x650 [btrfs]
process_one_work+0x22c/0x600
worker_thread+0x50/0x3b0
kthread+0x137/0x150
ret_from_fork+0x1f/0x30
-> #0 (&delayed_node->mutex){+.+.}-{3:3}:
check_prev_add+0x98/0xa20
validate_chain+0xa8c/0x2a00
__lock_acquire+0x56f/0xaa0
lock_acquire+0xa3/0x440
__mutex_lock+0xa0/0xaf0
__btrfs_release_delayed_node.part.0+0x3f/0x310 [btrfs]
btrfs_evict_inode+0x3bf/0x560 [btrfs]
evict+0xd6/0x1c0
dispose_list+0x48/0x70
prune_icache_sb+0x54/0x80
super_cache_scan+0x121/0x1a0
do_shrink_slab+0x175/0x420
shrink_slab+0xb1/0x2e0
shrink_node+0x192/0x600
balance_pgdat+0x31f/0x750
kswapd+0x206/0x510
kthread+0x137/0x150
ret_from_fork+0x1f/0x30
other info that might help us debug this:
Chain exists of:
&delayed_node->mutex --> &fs_info->chunk_mutex --> fs_reclaim
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(fs_reclaim);
lock(&fs_info->chunk_mutex);
lock(fs_reclaim);
lock(&delayed_node->mutex);
*** DEADLOCK ***
3 locks held by kswapd0/75:
#0 : ffffffff8b0c8040 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x5/0x30
#1 : ffffffff8b0b50b8 (shrinker_rwsem){++++}-{3:3}, at: shrink_slab+0x54/0x2e0
#2 : ffffa040e057c0e8 (&type->s_umount_key#26){++++}-{3:3}, at: trylock_super+0x16/0x50
stack backtrace:
CPU: 2 PID: 75 Comm: kswapd0 Not tainted 5.8.0-rc6-default+ #1191
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba527-rebuilt.opensuse.org 04/01/2014
Call Trace:
dump_stack+0x78/0xa0
check_noncircular+0x16f/0x190
check_prev_add+0x98/0xa20
validate_chain+0xa8c/0x2a00
__lock_acquire+0x56f/0xaa0
lock_acquire+0xa3/0x440
? __btrfs_release_delayed_node.part.0+0x3f/0x310 [btrfs]
__mutex_lock+0xa0/0xaf0
? __btrfs_release_delayed_node.part.0+0x3f/0x310 [btrfs]
? __lock_acquire+0x56f/0xaa0
? __btrfs_release_delayed_node.part.0+0x3f/0x310 [btrfs]
? lock_acquire+0xa3/0x440
? btrfs_evict_inode+0x138/0x560 [btrfs]
? btrfs_evict_inode+0x2fe/0x560 [btrfs]
? __btrfs_release_delayed_node.part.0+0x3f/0x310 [btrfs]
__btrfs_release_delayed_node.part.0+0x3f/0x310 [btrfs]
btrfs_evict_inode+0x3bf/0x560 [btrfs]
evict+0xd6/0x1c0
dispose_list+0x48/0x70
prune_icache_sb+0x54/0x80
super_cache_scan+0x121/0x1a0
do_shrink_slab+0x175/0x420
shrink_slab+0xb1/0x2e0
shrink_node+0x192/0x600
balance_pgdat+0x31f/0x750
kswapd+0x206/0x510
? _raw_spin_unlock_irqrestore+0x3e/0x50
? finish_wait+0x90/0x90
? balance_pgdat+0x750/0x750
kthread+0x137/0x150
? kthread_stop+0x2a0/0x2a0
ret_from_fork+0x1f/0x30
This is because we're holding the chunk_mutex while adding this device
and adding its sysfs entries. We actually hold different locks in
different places when calling this function, the dev_replace semaphore
for instance in dev replace, so instead of moving this call around
simply wrap it's operations in NOFS.
CC: stable@vger.kernel.org # 4.14+
Reported-by: David Sterba <dsterba@suse.com>
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-08-26 10:30:59 +02:00
2020-08-19 08:15:06 +02:00
2019-08-06 19:06:49 +02:00
2020-01-27 14:51:21 +01:00
2020-06-25 15:33:06 +02:00
2019-12-13 08:51:01 +01:00
2018-06-15 18:10:01 -03:00
2018-12-01 09:37:27 +01:00
2020-08-26 10:30:59 +02:00
2020-06-03 08:19:29 +02:00
2020-05-27 17:37:34 +02:00
2020-08-21 11:05:31 +02:00
2019-08-06 19:06:51 +02:00
2020-05-27 17:37:32 +02:00
2018-11-13 11:08:55 -08:00
2019-07-26 09:14:02 +02:00
2019-05-08 07:21:48 +02:00
2019-03-23 20:09:59 +01:00
2020-08-19 08:15:02 +02:00
2020-02-28 16:38:59 +01:00
2018-07-22 14:13:44 +02:00
2019-12-05 09:20:32 +01:00
2020-01-27 14:50:02 +01:00
2020-08-21 11:05:32 +02:00
2020-08-07 09:36:21 +02:00
2020-06-25 15:32:49 +02:00
2020-06-22 09:05:08 +02:00
2018-12-17 09:24:40 +01:00
2020-07-29 10:16:46 +02:00
2020-07-22 09:32:01 +02:00
2019-12-01 09:17:10 +01:00
2020-04-17 10:48:52 +02:00
2018-08-17 16:20:28 -07:00
2018-08-25 12:42:33 -07:00
2019-05-22 07:37:40 +02:00
2018-08-21 11:37:41 +02:00
2020-04-21 09:03:06 +02:00
2019-05-08 07:21:48 +02:00
2020-01-27 14:50:33 +01:00
2019-12-13 08:52:43 +01:00
2019-12-13 08:51:59 +01:00
2020-08-21 11:05:38 +02:00
2020-08-21 11:05:38 +02:00
2020-07-09 09:37:11 +02:00
2020-06-22 09:05:03 +02:00
2020-06-30 23:17:00 -04:00
2018-08-17 16:20:27 -07:00
2020-08-21 11:05:33 +02:00
2020-02-24 08:34:53 +01:00
2020-07-22 09:32:10 +02:00
2020-06-22 09:05:06 +02:00
2020-08-19 08:15:04 +02:00
2020-01-12 12:17:20 +01:00
2020-02-24 08:34:52 +01:00
2018-08-02 09:34:02 -07:00
2018-08-18 11:44:53 -07:00
2018-12-17 09:24:30 +01:00
2018-07-31 11:32:44 -04:00
2020-05-27 17:37:30 +02:00
2020-02-24 08:34:45 +01:00
2020-08-21 11:05:38 +02:00
2020-08-19 08:14:56 +02:00
2020-06-22 09:05:01 +02:00
2018-07-12 10:04:27 -04:00
2018-07-03 16:44:45 -04:00
2018-07-12 10:04:20 -04:00
2018-06-12 16:19:22 -07:00
2020-06-03 08:19:41 +02:00
2019-07-03 13:14:44 +02:00
2018-07-10 23:29:03 -04:00
2019-11-06 13:05:37 +01:00
2020-06-25 15:33:06 +02:00
2020-04-23 10:30:12 +02:00
2020-01-14 20:06:57 +01:00
2020-01-09 10:19:07 +01:00
2018-06-05 19:23:26 +02:00
2020-05-14 07:57:21 +02:00
2020-03-05 16:42:12 +01:00
2019-05-25 18:23:26 +02:00
2019-03-05 17:58:50 +01:00
2020-01-12 12:17:20 +01:00
2020-02-11 04:34:08 -08:00
2019-02-12 19:47:19 +01:00
2020-05-20 08:18:50 +02:00
2018-08-15 23:03:20 -05:00
2018-08-21 18:19:09 -07:00
2020-05-27 17:37:29 +02:00
2020-04-17 10:48:51 +02:00
2020-06-22 09:05:03 +02:00
2020-03-25 08:06:14 +01:00
2019-05-31 06:46:05 -07:00
2018-11-21 09:19:14 +01:00
2019-12-13 08:52:56 +01:00
2018-06-11 08:22:34 -07:00
2018-08-02 08:06:55 +09:00
2020-04-02 15:28:21 +02:00
2020-01-09 10:19:00 +01:00
2018-06-11 08:22:34 -07:00
2018-06-12 16:19:22 -07:00
2018-08-17 16:20:29 -07:00
2020-03-05 16:42:20 +01:00
2020-04-29 16:31:26 +02:00
2019-05-25 18:23:26 +02:00
2020-03-18 07:14:21 +01:00
2019-05-04 09:20:11 +02:00
2020-05-02 17:26:01 +02:00
2019-12-01 09:17:04 +01:00
2020-01-04 19:13:26 +01:00
2018-06-28 10:40:47 -07:00
2019-08-25 10:47:43 +02:00
2018-06-16 16:21:50 +09:00
2019-12-17 20:35:43 +01:00
2019-10-11 18:21:39 +02:00
2018-08-26 11:48:42 -07:00
2018-08-13 20:56:23 -07:00
2020-01-04 19:13:18 +01:00
2020-08-11 15:32:34 +02:00
76c3819639