@@ -26,6 +26,7 @@ _cleanup()
# get standard environment, filters and checks
. ./common/rc
. ./common/filter
+. ./common/module
# remove previous $seqres.full before test
rm -f $seqres.full
@@ -37,6 +38,7 @@ _supported_fs btrfs
_supported_os Linux
_require_command "$BTRFS_TUNE_PROG" btrfstune
_require_scratch_dev_pool 2
+_require_loadable_fs_module "btrfs"
_scratch_dev_pool_get 2
@@ -61,7 +63,8 @@ create_sprout()
{
_run_btrfs_util_prog device add -f $dev_sprout $SCRATCH_MNT
_scratch_unmount
- run_check _mount $dev_sprout $SCRATCH_MNT
+ _reload_fs_module "btrfs"
+ run_check _mount -o device=$dev_seed $dev_sprout $SCRATCH_MNT
echo -- sprout --
od -x $SCRATCH_MNT/foobar
_scratch_unmount
Hi, I can reproduce the below circular locking warning [1] using the test case btrfs/161. It can also be reproduced with 4.1 kernel so its not due to any of the recent patches. And this warning is unreasonable too .. here is why. From [1], Thread #0 is when mounting the sprout device, and thread #1 is when the sprout device is being added to the seed device. As they both can't be in the same time space this circular locking can't be practical. One way to workaround this, is to change the address of the fs_devices across unmount mount cycle, just by reloading the btrfs.ko [2]. and this warning goes away. But, for now I am going to ignore this warning. Any feedback/suggestion? pls let me know. By the way is there anyway not to disable the lockdep check after the first report? Thanks, Anand [1] ------------------------------------------------------------------------- [ 47.246043] ====================================================== [ 47.247177] WARNING: possible circular locking dependency detected [ 47.248239] 4.17.0-rc7+ #5 Not tainted [ 47.248924] ------------------------------------------------------ [ 47.250282] mount/3470 is trying to acquire lock: [ 47.251132] 00000000a04c7a49 (&fs_devs->device_list_mutex){+.+.}, at: clone_fs_devices+0x3d/0x170 [btrfs] [ 47.252913] but task is already holding lock: [ 47.254056] 00000000d4401221 (&fs_info->chunk_mutex){+.+.}, at: btrfs_read_chunk_tree+0x67/0x750 [btrfs] [ 47.255673] which lock already depends on the new lock. [ 47.257178] the existing dependency chain (in reverse order) is: [ 47.258480] -> #1 (&fs_info->chunk_mutex){+.+.}: [ 47.261529] btrfs_init_new_device+0x553/0x1060 [btrfs] [ 47.262532] btrfs_ioctl+0xa33/0x22a0 [btrfs] [ 47.263411] do_vfs_ioctl+0x635/0x680 [ 47.264208] ksys_ioctl+0x4e/0x80 [ 47.264932] __x64_sys_ioctl+0x16/0x20 [ 47.265715] do_syscall_64+0x57/0x150 [ 47.266493] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 47.267516] -> #0 (&fs_devs->device_list_mutex){+.+.}: [ 47.268923] __mutex_lock+0x7f/0x990 [ 47.270068] clone_fs_devices+0x3d/0x170 [btrfs] [ 47.270982] btrfs_read_chunk_tree+0x280/0x750 [btrfs] [ 47.271986] open_ctree+0x1545/0x2180 [btrfs] [ 47.272870] btrfs_mount_root+0x49f/0x790 [btrfs] [ 47.273797] mount_fs+0x89/0x130 [ 47.274543] vfs_kern_mount+0x69/0x160 [ 47.275378] btrfs_mount+0x181/0x8f0 [btrfs] [ 47.276265] mount_fs+0x89/0x130 [ 47.277038] vfs_kern_mount+0x69/0x160 [ 47.277875] do_mount+0x915/0xd10 [ 47.278648] ksys_mount+0x8d/0xc0 [ 47.279382] __x64_sys_mount+0x21/0x30 [ 47.280174] do_syscall_64+0x57/0x150 [ 47.280924] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 47.281885] other info that might help us debug this: [ 47.283385] Possible unsafe locking scenario: [ 47.284488] CPU0 CPU1 [ 47.285339] ---- ---- [ 47.286160] lock(&fs_info->chunk_mutex); [ 47.286898] lock(&fs_devs->device_list_mutex); [ 47.288130] lock(&fs_info->chunk_mutex); [ 47.307756] lock(&fs_devs->device_list_mutex); [ 47.308552] *** DEADLOCK *** ------------------------ Thread #0 ------------------------------------ btrfs_read_chunk_tree() :: mutex_lock(&uuid_mutex); mutex_lock(&fs_info->chunk_mutex); <---- :: ret = read_one_dev(fs_info, leaf, dev_item); read_one_dev() :: fs_devices = open_seed_devices(fs_info, fs_uuid); open_seed_devices() :: fs_devices = find_fsid(fsid); :: fs_devices = clone_fs_devices(fs_devices); clone_fs_devices(orig) :: mutex_lock(&orig->device_list_mutex); <--- ------------------------------------ Thread #1 ------------------------------------ static int btrfs_prepare_sprout(struct btrfs_fs_info *fs_info) mutex_lock(&fs_info->fs_devices->device_list_mutex); <--- :: mutex_lock(&fs_info->chunk_mutex); <--- ------------------------------------- [2] --------------------- ---------------------------------- Thanks, Anand -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html