Miklos Szeredi <mik...@szeredi.hu> 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-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/