Lockdep is reporting:
chmod/16751 is trying to acquire lock:
(&lli->lli_lsm_sem){++++}-{3:3}, at: ll_update_dir_depth+0x8b/0x280
but task is already holding lock:
(&lli->lli_lsm_sem){++++}-{3:3}, at: ll_update_dir_depth+0x7b/0x280
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&lli->lli_lsm_sem);
lock(&lli->lli_lsm_sem);
*** DEADLOCK ***
May be due to missing lock nesting notation
Lockdep sees acquiring more than one lock of the same lock class
as a potential dead lock. The execption is if the locks are used
for objects that belong to a hierarchy. For our case of the
lsm_sem we do have a hierarchy since a lsm for a child directory
is related to the parent directory lsm that is being protected
as well. Create new lock classes for the lsm_sem with proper
ordering.
Change-Id: I06c890d16816b83492cbeadabde3515ee0233424
Signed-off-by: James Simmons <jsimmons@infradead.org>
Reviewed-on: https://review.whamcloud.com/c/fs/lustre-release/+/51192
Reviewed-by: Arshad Hussain <arshad.hussain@aeoncomputing.com>
Reviewed-by: Oleg Drokin <green@whamcloud.com>
Reviewed-by: Lai Siyao <lai.siyao@whamcloud.com>
Reviewed-by: Andreas Dilger <adilger@whamcloud.com>
Tested-by: jenkins <devops@whamcloud.com>
Tested-by: Maloo <maloo@whamcloud.com>
return rc;
}
+enum lsm_sem_class {
+ LSM_SEM_PARENT,
+ LSM_SEM_CHILD,
+};
+
/**
* Update directory depth and default LMV
*
lli->lli_dir_depth = plli->lli_dir_depth + 1;
if (lli->lli_default_lsm_md && lli->lli_default_lmv_set) {
if (plli->lli_default_lsm_md) {
- down_read(&plli->lli_lsm_sem);
- down_read(&lli->lli_lsm_sem);
+ down_read_nested(&plli->lli_lsm_sem, LSM_SEM_PARENT);
+ down_read_nested(&lli->lli_lsm_sem, LSM_SEM_CHILD);
if (lsm_md_inherited(plli->lli_default_lsm_md,
lli->lli_default_lsm_md))
lli->lli_inherit_depth =