[LU-2487] 2.2 Client deadlock between ll_md_blocking_ast, sys_close, and sys_open

Related — Thu, 3 Oct 2013 16:35:00 +0000

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

Whamcloud Community JIRA

[LU-2487] 2.2 Client deadlock between ll_md_blocking_ast, sys_close, and sys_open