"possible recursive locking detected" when creating zpool

[dechamps]

With zfs-0.6.0-rc8, when creating a zpool with approx. 40 disks in it, with a kernel compiled with lock debugging support, I got this:

=============================================
[ INFO: possible recursive locking detected ]
3.2.18 #4
---------------------------------------------
vdev_open/1/6865 is trying to acquire lock:
(&zio->io_lock){+.+...}, at: [<ffffffffa01e6843>] zio_add_child+0x93/0x220 [zfs]

but task is already holding lock:
(&zio->io_lock){+.+...}, at: [<ffffffffa01e681d>] zio_add_child+0x6d/0x220 [zfs]

other info that might help us debug this:
Possible unsafe locking scenario:

      CPU0
      ----
 lock(&zio->io_lock);
 lock(&zio->io_lock);

*** DEADLOCK ***

May be due to missing lock nesting notation

1 lock held by vdev_open/1/6865:
#0:  (&zio->io_lock){+.+...}, at: [<ffffffffa01e681d>] zio_add_child+0x6d/0x220 [zfs]

stack backtrace:
Pid: 6865, comm: vdev_open/1 Tainted: G           O 3.2.18-leclercng-std-ipv6-64 #4
Call Trace:
[<ffffffff810bedea>] validate_chain+0xeea/0x1370
[<ffffffff810b9cff>] ? save_trace+0x3f/0xc0
[<ffffffff810adc35>] ? sched_clock_cpu+0xc5/0x100
[<ffffffff810bf7ca>] __lock_acquire+0x55a/0xc10
[<ffffffffa00064e5>] ? spl_kmem_cache_alloc+0x155/0x13a0 [spl]
[<ffffffff810c04f9>] lock_acquire+0x99/0xc0
[<ffffffffa01e6843>] ? zio_add_child+0x93/0x220 [zfs]
[<ffffffff81b7c13d>] ? mutex_lock_nested+0x2bd/0x390
[<ffffffff81b7bef2>] mutex_lock_nested+0x72/0x390
[<ffffffffa01e6843>] ? zio_add_child+0x93/0x220 [zfs]
[<ffffffffa01e6843>] ? zio_add_child+0x93/0x220 [zfs]
[<ffffffffa01e6843>] zio_add_child+0x93/0x220 [zfs]
[<ffffffffa01e807b>] zio_create+0x46b/0x7d0 [zfs]
[<ffffffffa000a79f>] ? __taskq_init_ent+0x1f/0x60 [spl]
[<ffffffffa01e89d9>] zio_read_phys+0x109/0x200 [zfs]
[<ffffffffa0194870>] ? vdev_open_child+0x40/0x40 [zfs]
[<ffffffffa019348c>] vdev_probe+0x12c/0x2e0 [zfs]
[<ffffffffa0194870>] ? vdev_open_child+0x40/0x40 [zfs]
[<ffffffffa01b8a60>] ? zfs_post_state_change+0x10/0x20 [zfs]
[<ffffffffa0193990>] vdev_open+0x350/0x6e0 [zfs]
[<ffffffffa0194851>] vdev_open_child+0x21/0x40 [zfs]
[<ffffffffa000c042>] taskq_thread+0x282/0x880 [spl]
[<ffffffff810adcbf>] ? local_clock+0x4f/0x60
[<ffffffff810842c0>] ? try_to_wake_up+0x2e0/0x2e0
[<ffffffffa000bdc0>] ? spl_taskq_init+0x180/0x180 [spl]
[<ffffffff810a7496>] kthread+0xa6/0xb0
[<ffffffff81b808b4>] kernel_thread_helper+0x4/0x10
[<ffffffff81b7e05d>] ? retint_restore_args+0xe/0xe
[<ffffffff810a73f0>] ? __init_kthread_worker+0x70/0x70
[<ffffffff81b808b0>] ? gs_change+0xb/0xb

[behlendorf]

Yes, this is a bit of a known issue. The way ZFS does some of its locking causes false positives with the Linux lock dependency analysis. All the deadlocks it reports are bogus and can be ignored, however until we rework some locking the ZFS code to be lock dep friendly enabling it isn't very useful. I've been meaning to do this for a long time now...

[dechamps]

Closing since I just noticed this is an exact duplicate of #488.