ocfs2/dlm: the mig_request could be for recovery

PATCH New Wengang Wang 1 participant 2 messages May 25, 2010 – Jun 11, 2010 OCFS2

lore

Share & tools

lore

Wengang Wang

author

2010-05-25 13:01 UTC #0 lore raw

PATCH 1/1 ocfs2/dlm: the mig_request could be for recovery

I hit a bug, it's the BUG_ON() in

1780 * do not allocate a new lock structure. */
1781 if (ml->node == dlm->node_num) {
1782 /* MIGRATION ONLY! */
1783 BUG_ON(!(mres->flags & DLM_MRES_MIGRATION));
1784
1785 spin_lock(&res->spinlock);

in dlm_process_recovery_data().

I think it's possible it's a mig_request for recovery in the following case:

1) Node A and node B have ref on lockres A mastered by node C. So on node C the is a lock on behalf of A, lock A, on lockres A.
2) For umount, node C is migrating lockres A to node B. the migration mle, master being node C, new master being node B, is created and added to mle hashtable.
3) Node B "down". Node A is the recovery master. On node C, lockres A also become the object to recovery because it's during migration and the new master is the "down" node B.
4) Node C send mig_request request(for recovery) to node A for lockres A including lock A.
5) receiving the mig_request from node C(for recovery), node A BUG()ed because of lock A.

fix:
removing the BUG_ON() is OK.

Well, I can't reproduce the bug. So didn't test the fix.

Signed-off-by Wengang Wang <[email protected]>

---
 fs/ocfs2/dlm/dlmrecovery.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

fs/ocfs2/dlm/dlmrecovery.c +0 -1

index b4f99de..03f17d5 100644
@@ -1780,7 +1780,6 @@ static int dlm_process_recovery_data(struct dlm_ctxt *dlm,
 		 * do not allocate a new lock structure. */
 		if (ml->node == dlm->node_num) {
 			/* MIGRATION ONLY! */
-			BUG_ON(!(mres->flags & DLM_MRES_MIGRATION));
 
 			spin_lock(&res->spinlock);
 			for (j = DLM_GRANTED_LIST; j <= DLM_BLOCKED_LIST; j++) {

Signature · 1 line

1.6.6.1

Wengang Wang

author

2010-06-11 10:27 UTC #1 lore raw

PATCH 1/1 ocfs2/dlm: the mig_request could be for recovery

Any comment?

regards,
wengang.

Quoted 56 lines · Wengang Wang

I hit a bug, it's the BUG_ON() in
1780 * do not allocate a new lock structure. */
1781 if (ml->node == dlm->node_num) {
1782 /* MIGRATION ONLY! */
1783 BUG_ON(!(mres->flags & DLM_MRES_MIGRATION));
1784
1785 spin_lock(&res->spinlock);
in dlm_process_recovery_data().
I think it's possible it's a mig_request for recovery in the following case:
1) Node A and node B have ref on lockres A mastered by node C. So on node C the is a lock on behalf of A, lock A, on lockres A.
2) For umount, node C is migrating lockres A to node B. the migration mle, master being node C, new master being node B, is created and added to mle hashtable.
3) Node B "down". Node A is the recovery master. On node C, lockres A also become the object to recovery because it's during migration and the new master is the "down" node B.
4) Node C send mig_request request(for recovery) to node A for lockres A including lock A.
5) receiving the mig_request from node C(for recovery), node A BUG()ed because of lock A.
fix:
removing the BUG_ON() is OK.
Well, I can't reproduce the bug. So didn't test the fix.
Signed-off-by Wengang Wang <[email protected]>
---
 fs/ocfs2/dlm/dlmrecovery.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)
fs/ocfs2/dlm/dlmrecovery.c +0 -1
index b4f99de..03f17d5 100644
@@ -1780,7 +1780,6 @@ static int dlm_process_recovery_data(struct dlm_ctxt *dlm,
 		 * do not allocate a new lock structure. */
 		if (ml->node == dlm->node_num) {
 			/* MIGRATION ONLY! */
-			BUG_ON(!(mres->flags & DLM_MRES_MIGRATION));
 
 			spin_lock(&res->spinlock);
 			for (j = DLM_GRANTED_LIST; j <= DLM_BLOCKED_LIST; j++) {
Signature · 7 lines
1.6.6.1


_______________________________________________
Ocfs2-devel mailing list
Ocfs2-devel at oss.oracle.com
http://oss.oracle.com/mailman/listinfo/ocfs2-devel