Skip to contentSkip to conversation

ocfs2: Do not downconvert if the lock level is already compatible

PATCH New Sunil Mushran 3 participants 4 messages Jan 29, 2010 OCFS2

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 ocfs2: Do not downconvert if the lock level is already compatible

During upconvert, if the master were to send a BAST, dlmglue will detect the upconversion in process and send a cancel convert to the master. Upon receiving the AST for the cancel convert, it will re-process the lock resource to determine whether it needs downconverting. Say, the up was from PR to EX and the BAST was for EX. After the cancel convert, it will need to downconvert to NL.

However, if the node was originally upconverting from NL to EX, then there would be no reason to downconvert (assuming the same message sequence).

This patch makes dlmglue consider the possibility that the current lock level is already compatible and that downconverting is not required.

Joel Becker <[email protected]> assisted in fixing this issue.

Fixes ossbz#1178
http://oss.oracle.com/bugzilla/show_bug.cgi?id=1178

---
 fs/ocfs2/dlmglue.c |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)
fs/ocfs2/dlmglue.c +13 -0
index f7b9f8f..2918c2c 100644
@@ -3445,6 +3445,19 @@ recheck:
 	if (lockres->l_flags & OCFS2_LOCK_UPCONVERT_FINISHING)
 		goto leave_requeue;
 
+	/*
+	 * How can we block and yet be at NL?  We were trying to upconvert
+	 * from NL and got canceled.  The code comes back here, and now
+	 * we notice and clear BLOCKING.
+	 */
+	if (lockres->l_level == DLM_LOCK_NL) {
+		BUG_ON(lockres->l_ex_holders || lockres->l_ro_holders);
+		lockres->l_blocking = DLM_LOCK_NL;
+		lockres_clear_flags(lockres, OCFS2_LOCK_BLOCKED);
+		spin_unlock_irqrestore(&lockres->l_lock, flags);
+		goto leave;
+	}
+
 	/* if we're blocking an exclusive and we have *any* holders,
 	 * then requeue. */
 	if ((lockres->l_blocking == DLM_LOCK_EX)
Signature · 1 line
1.6.3.3
#1 lore raw

PATCH 1/1 ocfs2: Do not downconvert if the lock level is already compatible

Quoted 12 lines · Sunil Mushran

During upconvert, if the master were to send a BAST, dlmglue will detect the upconversion in process and send a cancel convert to the master. Upon receiving the AST for the cancel convert, it will re-process the lock resource to determine whether it needs downconverting. Say, the up was from PR to EX and the BAST was for EX. After the cancel convert, it will need to downconvert to NL.

However, if the node was originally upconverting from NL to EX, then there would be no reason to downconvert (assuming the same message sequence).

This patch makes dlmglue consider the possibility that the current lock level is already compatible and that downconverting is not required.

Quoted 7 lines

Joel Becker <[email protected]> assisted in fixing this issue.

Fixes ossbz#1178
http://oss.oracle.com/bugzilla/show_bug.cgi?id=1178

Hmm, looks like it's the month of dlmglue fixes? :)

	--Mark

--
Mark Fasheh

#2 lore raw

PATCH 1/1 ocfs2: Do not downconvert if the lock level is already compatible

Quoted 1 line · Mark Fasheh

Hmm, looks like it's the month of dlmglue fixes? :)

fs/dlm is far more asynchronous than o2dlm, and boy it shows us
up ;-)

Joel

Signature · 9 lines
Life's Little Instruction Book #396

	"Never give anyone a fruitcake."

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker at oracle.com
Phone: (650) 506-8127
#3 lore raw

PATCH 1/1 ocfs2: Do not downconvert if the lock level is already compatible

Quoted 5 lines · Joel Becker
Quoted 1 line · Mark Fasheh

Hmm, looks like it's the month of dlmglue fixes? :)

fs/dlm is far more asynchronous than o2dlm, and boy it shows us
up ;-)

True. In this case, it is bast-ing even before the ast. ;)