Details
-
Improvement
-
Resolution: Fixed
-
Minor
-
Lustre 2.5.0
-
8426
Description
Got bellow lockdep warning during tests. It is false alarm though. We should use nested spin_lock.
[ 1184.479097] =============================================
[ 1184.479187] [ INFO: possible recursive locking detected ]
[ 1184.479277] 3.10.0-rc3+ #13 Tainted: G C
[ 1184.479355] ---------------------------------------------
[ 1184.479444] mkdir/2215 is trying to acquire lock:
[ 1184.479521] (&(&dentry->d_lock)->rlock){....}, at: [<ffffffffa06cc27c>] ll_md_blocking_ast+0x55c/0x655 [lustre]
[ 1184.479801]
but task is already holding lock:
[ 1184.479895] (&(&dentry->d_lock)->rlock){....}, at: [<ffffffffa06cc1b1>] ll_md_blocking_ast+0x491/0x655 [lustre]
[ 1184.480101]
other info that might help us debug this:
[ 1184.480206] Possible unsafe locking scenario:
[ 1184.480300] CPU0
[ 1184.480340] ----
[ 1184.480380] lock(&(&dentry->d_lock)->rlock);
[ 1184.480458] lock(&(&dentry->d_lock)->rlock);
[ 1184.480536]
-
-
- DEADLOCK ***
-
[ 1184.480761] May be due to missing lock nesting notation
[ 1184.480936] 4 locks held by mkdir/2215:
[ 1184.481037] #0: (sb_writers#11)
, at: [<ffffffff811531a9>] mnt_want_write+0x24/0x4b
[ 1184.481273] #1: (&type->i_mutex_dir_key#3/1){..+.}, at: [<ffffffff81144fce>] kern_path_create+0x8c/0x144
[ 1184.481513] #2: (&sb->s_type->i_lock_key#19){....}, at: [<ffffffffa06cc180>] ll_md_blocking_ast+0x460/0x655 [lustre]
[ 1184.481778] #3: (&(&dentry->d_lock)->rlock){....}, at: [<ffffffffa06cc1b1>] ll_md_blocking_ast+0x491/0x655 [lustre]
[ 1184.482050]