Whamcloud - gitweb
LU-5344 llite: lookup master inode by ilookup5_nowait 66/16066/8
authorwang di <di.wang@intel.com>
Sat, 22 Aug 2015 20:54:52 +0000 (13:54 -0700)
committerOleg Drokin <oleg.drokin@intel.com>
Sat, 19 Sep 2015 03:22:32 +0000 (03:22 +0000)
commitd06433141bbd83e523bc611f23cb1b42935830f4
tree4fef23248f49608eb3e8f111ead58128822877e5
parent7f67aa42f9123caef3cee714f1e2cee3c6848892
LU-5344 llite: lookup master inode by ilookup5_nowait

Do not lookup master inode by ilookup5, instead it should
use ilookup5_nowait, otherwise it will cause dead lock,

1. Client1 send chmod req to the MDT0, then on MDT0, it
enqueues master and all of its slaves lock, (mdt_attr_set()
->mdt_lock_slaves()), after gets master and stripe0 lock,
it will send the enqueue request(for stripe1) to MDT1, then
MDT1 finds the lock has been granted to client2. Then MDT1
sends blocking ast to client2.

2. At the same time, client2 tries to unlink the striped
dir (rm -rf striped_dir), and during lookup, it will hold
the master inode of the striped directory, whose inode state
is NEW, then tries to revalidate all of its slaves,
(ll_prep_inode()->ll_iget()->ll_read_inode2()->
ll_update_inode().). And it will be blocked on the server
side because of 1.

3.Then the client get the blocking_ast request, cancel the
lock, but being blocked by ilookup5 in ll_md_blocking_ast(),
because the inode state is still NEW.

Add test_90/91 in sanityn.sh to verify the deadlock

Signed-off-by: wang di <di.wang@intel.com>
Change-Id: I8ce88595998dc35b6165951873192a65674bf3a7
Reviewed-on: http://review.whamcloud.com/16066
Tested-by: Jenkins
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: John L. Hammond <john.hammond@intel.com>
Reviewed-by: Lai Siyao <lai.siyao@intel.com>
Reviewed-by: James Simmons <uja.ornl@yahoo.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
lustre/llite/namei.c
lustre/tests/sanityn.sh