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
