zfsonlinux/zfs — Issue #488: Running `zpool import -f tank`: "[ INFO: possible recursive locking detected ]"
Author: Prakash-Surya
Created: 2011-12-12 17:58:25+00:00
State: open

When running the `zpool import -f tank` with `CONFIG_LOCK_STAT` enabled, I found the following message in the `dmesg` output:

=============================================
[ INFO: possible recursive locking detected ]
2.6.32-220.1chaos.ch5.x86_64.debug #1
---------------------------------------------
vdev_open/1/8480 is trying to acquire lock:
(&zio->io_lock){+.+...}, at: [] zio_add_child+0x88/0x150 [zfs]

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

other info that might help us debug this:
1 lock held by vdev_open/1/8480:
#0: (&zio->io_lock){+.+...}, at: [] zio_add_child+0x62/0x150 [zfs]

stack backtrace:
Pid: 8480, comm: vdev_open/1 Tainted: G W ---------------- 2.6.32-220.1chaos.ch5.x86_64.debug #1
Call Trace:
[] ? __lock_acquire+0x11c0/0x1570
[] ? __alloc_pages_nodemask+0x13b/0xa20
[] ? native_sched_clock+0x13/0x60
[] ? sched_clock+0x9/0x10
[] ? lock_acquire+0xa4/0x120
[] ? zio_add_child+0x88/0x150 [zfs]
[] ? mark_held_locks+0x73/0xa0
[] ? __mutex_lock_common+0x2b7/0x400
[] ? __mutex_lock_common+0x43/0x400
[] ? zio_add_child+0x88/0x150 [zfs]
[] ? zio_add_child+0x88/0x150 [zfs]
[] ? mutex_lock_nested+0x48/0x60
[] ? zio_add_child+0x88/0x150 [zfs]
[] ? zio_create+0x3e8/0x4b0 [zfs]
[] ? zio_read_phys+0x6e/0x80 [zfs]
[] ? vdev_probe_done+0x0/0x270 [zfs]
[] ? vdev_probe+0x14a/0x250 [zfs]
[] ? vdev_probe_done+0x0/0x270 [zfs]
[] ? zfs_post_state_change+0x15/0x20 [zfs]
[] ? vdev_open+0x260/0x3e0 [zfs]
[] ? vdev_open_child+0x26/0x40 [zfs]
[] ? taskq_thread+0x1e5/0x360 [spl]
[] ? default_wake_function+0x0/0x20
[] ? taskq_thread+0x0/0x360 [spl]
[] ? kthread+0x96/0xa0
[] ? child_rip+0xa/0x20
[] ? restore_args+0x0/0x30
[] ? kthread+0x0/0xa0
[] ? child_rip+0x0/0x20
SPL: Showing stack for process 11540
Pid: 11540, comm: mount Tainted: G W ---------------- 2.6.32-220.1chaos.ch5.x86_64.debug #1
Call Trace:
[] ? spl_debug_dumpstack+0x27/0x40 [spl]
[] ? kmem_alloc_debug+0x11d/0x130 [spl]
[] ? zfs_sb_create+0x48/0x5a0 [zfs]
[] ? zpl_fill_super+0x0/0x20 [zfs]
[] ? zfs_domount+0x3e/0x350 [zfs]
[] ? sget+0x3e7/0x460
[] ? set_anon_super+0x0/0x110
[] ? zpl_fill_super+0x0/0x20 [zfs]
[] ? zpl_fill_super+0xe/0x20 [zfs]
[] ? get_sb_nodev+0x5f/0xa0
[] ? zpl_get_sb+0x25/0x30 [zfs]
[] ? vfs_kern_mount+0x7b/0x1b0
[] ? do_kern_mount+0x52/0x130
[] ? do_mount+0x2d2/0x8c0
[] ? copy_mount_options+0xf2/0x1a0
[] ? sys_mount+0x90/0xe0
[] ? system_call_fastpath+0x16/0x1b
lt-zpool used greatest stack depth: 1632 bytes left