lockdep warning is impractical
diff mbox

Message ID 83faa761-4b88-4651-e098-d6b39e2662d2@oracle.com
State New
Headers show

Commit Message

Anand Jain July 10, 2018, 6 p.m. UTC
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

Patch
diff mbox

diff --git a/tests/btrfs/161 b/tests/btrfs/161
index dfff8b871fa3..88e982d81e5b 100755
--- a/tests/btrfs/161
+++ b/tests/btrfs/161
@@ -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