Eddie Horng: > Thanks the information, but I still can reproduce it with aufs-4.10 and the > held lock patch.
Hmm... I am totally confused and lost my way. I don't understand what is happening. If anyone on this list has an idea which light up the way, I will be gladly become all ears. Your report can be summarized as ---------------------------------------- 41.315960 aufs 4.10-20171002 ::: ninja D 0 3376 1 0x00000004 Call Trace: __schedule+0x2db/0x910 ? schedule+0x3d/0x90 schedule+0x3d/0x90 schedule_preempt_disabled+0x15/0x20 mutex_lock_nested+0x21f/0x5d0 ? au_xino_delete_inode+0x1a3/0x1f0 aufs ? xino_fwrite+0xa0/0xb0 aufs au_xino_delete_inode+0x1a3/0x1f0 aufs au_iinfo_fin+0x100/0x130 aufs aufs_destroy_inode+0x47/0x50 aufs destroy_inode+0x3b/0x60 evict+0x132/0x190 iput+0x1f8/0x280 do_unlinkat+0x18f/0x2d0 SyS_unlink+0x16/0x20 entry_SYSCALL_64_fastpath+0x1e/0xb2 ::: clang++.real D 0 6173 1 0x00000006 Call Trace: __schedule+0x2db/0x910 ? mutex_spin_on_owner+0xb1/0xd0 ? mutex_spin_on_owner+0x5/0xd0 schedule+0x3d/0x90 schedule_preempt_disabled+0x15/0x20 mutex_lock_nested+0x21f/0x5d0 ? au_xino_delete_inode+0x1a3/0x1f0 aufs au_xino_delete_inode+0x1a3/0x1f0 aufs au_iinfo_fin+0x100/0x130 aufs aufs_destroy_inode+0x47/0x50 aufs destroy_inode+0x3b/0x60 evict+0x132/0x190 iput+0x1f8/0x280 dentry_unlink_inode+0xc3/0x160 __dentry_kill+0xc6/0x170 dput+0x1ea/0x310 ? dput+0x29/0x310 __fput+0x19e/0x240 ____fput+0xe/0x10 task_work_run+0x7e/0xb0 do_exit+0x323/0xbe0 ? __sigqueue_free.part.20+0x33/0x40 do_group_exit+0x50/0xd0 get_signal+0x2be/0x720 do_signal+0x28/0x770 exit_to_usermode_loop+0x76/0xb0 syscall_return_slowpath+0x62/0x70 entry_SYSCALL_64_fastpath+0xb0/0xb2 ::: Showing all locks held in the system: 3 locks held by ninja/3376: #0: (sb_writers#18) mnt_want_write+0x24/0x50 #1: (&sbinfo->si_rwsem) au_iinfo_fin+0xec/0x130 aufs #2: (&sbinfo->si_xib_mtx) au_xino_delete_inode+0x1a3/0x1f0 aufs 2 locks held by clang++.real/6173: #0: (&sbinfo->si_rwsem) au_iinfo_fin+0xec/0x130 aufs #1: (&sbinfo->si_xib_mtx) au_xino_delete_inode+0x1a3/0x1f0 aufs ---------------------------------------- These two processes have the very similar call stack. The common part is mutex_lock_nested au_xino_delete_inode au_iinfo_fin aufs_destroy_inode destroy_inode evict iput And the lockdep reports the suspicious mutex is sbinfo->si_xib_mtx in aufs. But I cannot find any problem around it. Eddie, I appriciate your repeated tests. It may be hard for you. But I have another request. Try enabling CONFIG_AUFS_DEBUG and reprducing the problem. Of course, I know that I should add "if you can, please" magic words. J. R. Okajima ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot