Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
> Fix now pushed to overlayfs.v22/overlayfs.current.
I ran my testscript, which leaves a clean set up and mounted overlay fs
behind. I then ran:
for ((i=100; i<=129; i++)); do mv /mnt/a/foo$i /mnt/a/bar$i; done
for ((i=100; i<=129; i++)); do mv /mnt/a/dir$i /mnt/a/dir2$i; done
leading to:
=============================================
[ INFO: possible recursive locking detected ]
3.15.0-rc6-fsdevel+ #382 Tainted: G W
---------------------------------------------
mv/27935 is trying to acquire lock:
(&sb->s_type->i_mutex_key#9){+.+.+.}, at: [<ffffffff8111e555>] vfs_rmdir+0x59/0xe8
but task is already holding lock:
(&sb->s_type->i_mutex_key#9){+.+.+.}, at: [<ffffffff811e12a9>] ovl_clear_empty+0x175/0x1eb
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&sb->s_type->i_mutex_key#9);
lock(&sb->s_type->i_mutex_key#9);
*** DEADLOCK ***
May be due to missing lock nesting notation
5 locks held by mv/27935:
#0: (sb_writers#15){.+.+.+}, at: [<ffffffff8112c06c>] mnt_want_write+0x1c/0x40
#1: (&sb->s_type->i_mutex_key#17/1){+.+.+.}, at: [<ffffffff8111eb96>] do_rmdir+0x9f/0x152
#2: (&sb->s_type->i_mutex_key#17){+.+.+.}, at: [<ffffffff8111e555>] vfs_rmdir+0x59/0xe8
#3: (sb_writers#8){.+.+.+}, at: [<ffffffff8112c06c>] mnt_want_write+0x1c/0x40
#4: (&sb->s_type->i_mutex_key#9){+.+.+.}, at: [<ffffffff811e12a9>] ovl_clear_empty+0x175/0x1eb
stack backtrace:
CPU: 1 PID: 27935 Comm: mv Tainted: G W 3.15.0-rc6-fsdevel+ #382
Hardware name: /DG965RY, BIOS MQ96510J.86A.0816.2006.0716.2308 07/16/2006
0000000000000000 ffff880038ac9af0 ffffffff8148b889 ffffffff81fda190
ffff880038ac9bb0 ffffffff81074b0e 0000000000000002 ffff88003823c890
0000000000000000 ffff880000000000 ffff880000000004 ffff880000000000
Call Trace:
[<ffffffff8148b889>] dump_stack+0x4d/0x66
[<ffffffff81074b0e>] __lock_acquire+0x75a/0x1861
[<ffffffff810762b6>] lock_acquire+0x9c/0x112
[<ffffffff8111e555>] ? vfs_rmdir+0x59/0xe8
[<ffffffff8148e6df>] mutex_lock_nested+0x60/0x2ff
[<ffffffff8111e555>] ? vfs_rmdir+0x59/0xe8
[<ffffffff8111e555>] vfs_rmdir+0x59/0xe8
[<ffffffff811e0fbe>] ovl_cleanup+0x1d/0x40
[<ffffffff811e12b4>] ovl_clear_empty+0x180/0x1eb
[<ffffffff811e1360>] ovl_check_empty_and_clear+0x41/0x5c
[<ffffffff81058fcc>] ? creds_are_invalid+0x18/0x45
[<ffffffff811e1aca>] ovl_do_remove+0x17c/0x35e
[<ffffffff811e1cbd>] ovl_rmdir+0x11/0x13
[<ffffffff8111e584>] vfs_rmdir+0x88/0xe8
[<ffffffff8111ebdd>] do_rmdir+0xe6/0x152
[<ffffffff810af5b4>] ? __audit_syscall_entry+0xa1/0xc3
[<ffffffff8100d737>] ? syscall_trace_enter+0x197/0x1eb
[<ffffffff8111f414>] SyS_unlinkat+0x16/0x29
[<ffffffff814925f4>] tracesys+0xdd/0xe2
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
