[Ocfs2-devel] [PATCH] ocfs2: Plugs race between the dc thread and an unlock ast message

Sunil Mushran sunil.mushran at oracle.com
Fri Feb 5 10:39:47 PST 2010


Joel Becker wrote:
> 	Why cancel convert?  Why not an actual unlock.  That's what I
> thought you meant when you proposed the patch.  After all, David's bug
> was at DLM_LOCK_IV, not NL.
> 	Cancel isn't in play here.  Cancel only happens on the dc
> thread, and the dc thread has gotten past BUSY.  So the lock isn't busy
> anymore.  It does downconvert_worker in an unlocked state.  When it
> comes back to recheck, another thread can't have done a cancel.
> 	That's why I asked about unlink.  Imagine the dc thread is
> handling a bast while the unlink thread has gotten to clear_inode.
> Could ocfs2_drop_lock() be racing the downconvert?

Yes. I forgot the level was IV. So the full fix would be to ensure
the level is <= NL in the block below. ??


        /*
         * 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;
        }




More information about the Ocfs2-devel mailing list