ocfs2/dlm: move lock to the tail of grant queue while doing in-place convert
PATCH 1/1 ocfs2/dlm: move lock to the tail of grant queue while doing in-place convert
We have found a bug when two nodes doing umount one after another.
1) Node 1 migrate a lockres that has 3 locks in grant queue such as N2(PR)<->N3(NL)<->N4(PR) to N2. After migration, lvb of the lock N3(NL) and N4(PR) are empty on node 2 because migration target do not copy lvb to these two lock.
2) Node 3 want to convert to PR, it can be granted in __dlmconvert_master(), and the order of these locks is unchanged. The lvb of the lock N3(PR) on node 2 is copyed from lockres in function dlm_update_lvb() while the lvb of lock N4(PR) is still empty.
3) Node 2 want to leave domain, it will migrate this lockres to node 3. Then node 2 will trigger the BUG in dlm_prepare_lvb_for_migration() when adding the lock N4(PR) to mres with the following message because the lvb of mres is already copied from lock N3(PR), but the lvb of lock N4(PR) is empty.
"Mismatched lvb in lock cookie=%u:%llu, name=%.*s, node=%u"
--- fs/ocfs2/dlm/dlmconvert.c | 6 ++++++ 1 file changed, 6 insertions(+)
fs/ocfs2/dlm/dlmconvert.c +6 -0
@@ -212,6 +212,12 @@ grant:if (lock->lksb->flags &DLM_LKSB_PUT_LVB )memcpy (res->lvb, lock->lksb->lvb,DLM_LVB_LEN ); +/* +* move the lock to tail because it may be the only lock who has +* a invalid lvb. +*/ +list_move_tail (&lock->list, &res->granted); + status =DLM_NORMAL ; *call_ast =1 ; goto unlock_exit;
Signature · 1 line
1.8.4.3
PATCH 1/1 ocfs2/dlm: move lock to the tail of grant queue while doing in-place convert
Hello jiufei,
Quoted 27 lines · xuejiufei
We have found a bug when two nodes doing umount one after another.
1) Node 1 migrate a lockres that has 3 locks in grant queue such as N2(PR)<->N3(NL)<->N4(PR) to N2. After migration, lvb of the lock N3(NL) and N4(PR) are empty on node 2 because migration target do not copy lvb to these two lock.
2) Node 3 want to convert to PR, it can be granted in__dlmconvert_master(), and the order of these locks is unchanged. The lvb of the lock N3(PR) on node 2 is copyed from lockres in functiondlm_update_lvb()while the lvb of lock N4(PR) is still empty.
3) Node 2 want to leave domain, it will migrate this lockres to node 3. Then node 2 will trigger the BUG indlm_prepare_lvb_for_migration()when adding the lock N4(PR) to mres with the following message because the lvb of mres is already copied from lock N3(PR), but the lvb of lock N4(PR) is empty."Mismatched lvb in lock cookie=%u:%llu, name=%.*s, node=%u"
Signed-off-by xuejiufei <[email protected]>--- fs/ocfs2/dlm/dlmconvert.c | 6 ++++++ 1 file changed, 6 insertions(+)fs/ocfs2/dlm/dlmconvert.c +0
-0
fs/ocfs2/dlm/dlmconvert.c grant: · line 218
Quoted 7 lines
fs/ocfs2/dlm/dlmconvert.c +4
-0@@ -212,6 +212,12 @@ grant:if (lock->lksb->flags &DLM_LKSB_PUT_LVB )memcpy (res->lvb, lock->lksb->lvb,DLM_LVB_LEN ); +/* +* move the lock to tail because it may be the only lock who has +* a invalid lvb. +*/
I'm not fimiliar with ocfs2/dlm yet, just out of curious, by "invalid lvb" here it means when a lock has been upconvert in place, its lvb is invalid? If so, why not reset it than move?
Thanks,
Eric
Quoted 14 lines
fs/ocfs2/dlm/dlmconvert.c +2
-0+list_move_tail (&lock->list, &res->granted); + status =DLM_NORMAL ; *call_ast =1 ; goto unlock_exit;Signature · 7 lines
1.8.4.3 _______________________________________________ Ocfs2-devel mailing list Ocfs2-devel at oss.oracle.com https://oss.oracle.com/mailman/listinfo/ocfs2-devel
PATCH 1/1 ocfs2/dlm: move lock to the tail of grant queue while doing in-place convert
Hi Eric,
Quoted 33 lines · Eric Ren
Hello jiufei,
Quoted 30 lines · xuejiufei
We have found a bug when two nodes doing umount one after another.
1) Node 1 migrate a lockres that has 3 locks in grant queue such as N2(PR)<->N3(NL)<->N4(PR) to N2. After migration, lvb of the lock N3(NL) and N4(PR) are empty on node 2 because migration target do not copy lvb to these two lock.
2) Node 3 want to convert to PR, it can be granted in__dlmconvert_master(), and the order of these locks is unchanged. The lvb of the lock N3(PR) on node 2 is copyed from lockres in functiondlm_update_lvb()while the lvb of lock N4(PR) is still empty.
3) Node 2 want to leave domain, it will migrate this lockres to node 3. Then node 2 will trigger the BUG indlm_prepare_lvb_for_migration()when adding the lock N4(PR) to mres with the following message because the lvb of mres is already copied from lock N3(PR), but the lvb of lock N4(PR) is empty."Mismatched lvb in lock cookie=%u:%llu, name=%.*s, node=%u"
Signed-off-by xuejiufei <[email protected]>--- fs/ocfs2/dlm/dlmconvert.c | 6 ++++++ 1 file changed, 6 insertions(+)fs/ocfs2/dlm/dlmconvert.c +0
-0@@ -212,6 +212,12 @@ grant:if (lock->lksb->flags &DLM_LKSB_PUT_LVB )memcpy (res->lvb, lock->lksb->lvb,DLM_LVB_LEN );
Quoted 9 lines
fs/ocfs2/dlm/dlmconvert.c grant: · line 218
Quoted 4 lines
fs/ocfs2/dlm/dlmconvert.c +4
-0+/* +* move the lock to tail because it may be the only lock who has +* a invalid lvb. +*/ I'm not fimiliar with ocfs2/dlm yet, just out of curious, by "invalid lvb" here it means when a lock has been upconvert in place, its lvb is invalid? If so, why not reset it than move?
"invalid lvb" means that the lvb can not be trusted. After migration, lvb in all locks on master are invalid because the locks are new created. The lock been upconverted is valid after copy from lock resource on master.
Thanks,
Jiufei
Quoted 19 lines
Thanks,
EricQuoted 14 lines
fs/ocfs2/dlm/dlmconvert.c +2
-0+list_move_tail (&lock->list, &res->granted); + status =DLM_NORMAL ; *call_ast =1 ; goto unlock_exit;Signature · 7 lines
1.8.4.3 _______________________________________________ Ocfs2-devel mailing list Ocfs2-devel at oss.oracle.com https://oss.oracle.com/mailman/listinfo/ocfs2-devel.