Minor Description
Spinlock Usage
Walking through the code and digging through pointers in the stack frames of the 3 threads leads to the following 3 suspect structures and their related spinlocks:
inode = 0xffff880581a26638 (i_lock)
dentry = 0xffff88051f7242c0 (d_lock)
ldlm_resource = 0xffff880308f916c0 (lr_lock)
Looks like there is a 3 way deadlock between ll_md_blocking_ast, sys_open, and sys_close using the above spinlocks.
CPU 10: ll_md_blocking_ast()
+ ll_inode_from_resource() gets lock-l_resource->lr_lock
- igrab() wants lock->l_resource->lr_lvb_inode->i_lock
CPU 7: sys_close()
+ dput() gets dentry->d_lock
- ldlm_resource_foreach() wants res->lr_lock
CPU 15: sys_open
+ ll_splice_alias()/ll_find_alias() gets inode->i_lock
- ll_splice_alias()/ll_find_alias() wants dentry->d_lock
The lr_lock, d_lock, and i_lock are the same in all cases. So ll_md_blocking_ast() waits for sys_open(), sys_open waits for sys_close(), and sys_close() waits for ll_md_blocking_ast. A 3-way deadlock.
This deadlock is possible because of two pathces:
1) LU-903(not landed yet) (bz24555) - get inode lock. If we get ldlm_lock lock thin no deadlock possible.
resource dentry inode
ldlm_lock resource dentry
2) dcache_lock removing (http://review.whamcloud.com/#change,1865). Before this patch (with bz24555 enabled)also no deadlock possible.
resource dentry inode
inode resource dcache_lock
Attachments
Issue Links
- is related to
-
LU-4053 client leaking objects/locks during IO
-
- Resolved
-