Commit 0d74125a6a68d4f1969ecaf0b3543f315916ccdc

Authored by Sunil Mushran
Committed by Joel Becker
1 parent a191282601

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 <joel.becker@oracle.com> assisted in fixing this issue.

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

Reported-by: Coly Li <coly.li@suse.de>
Signed-off-by: Sunil Mushran <sunil.mushran@oracle.com>
Signed-off-by: Joel Becker <joel.becker@oracle.com>

Showing 1 changed file with 13 additions and 0 deletions Side-by-side Diff

... ... @@ -3445,6 +3445,19 @@
3445 3445 if (lockres->l_flags & OCFS2_LOCK_UPCONVERT_FINISHING)
3446 3446 goto leave_requeue;
3447 3447  
  3448 + /*
  3449 + * How can we block and yet be at NL? We were trying to upconvert
  3450 + * from NL and got canceled. The code comes back here, and now
  3451 + * we notice and clear BLOCKING.
  3452 + */
  3453 + if (lockres->l_level == DLM_LOCK_NL) {
  3454 + BUG_ON(lockres->l_ex_holders || lockres->l_ro_holders);
  3455 + lockres->l_blocking = DLM_LOCK_NL;
  3456 + lockres_clear_flags(lockres, OCFS2_LOCK_BLOCKED);
  3457 + spin_unlock_irqrestore(&lockres->l_lock, flags);
  3458 + goto leave;
  3459 + }
  3460 +
3448 3461 /* if we're blocking an exclusive and we have *any* holders,
3449 3462 * then requeue. */
3450 3463 if ((lockres->l_blocking == DLM_LOCK_EX)