ocfs2-devel.oss.oracle.com archive mirror
 help / color / mirror / Atom feed
From: Sunil Mushran <sunil.mushran@oracle.com>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [PATCH 1/2] ocfs2 fix o2dlm dlm run purgelist
Date: Thu, 17 Jun 2010 08:06:45 -0700	[thread overview]
Message-ID: <4C1A3A05.10704@oracle.com> (raw)
In-Reply-To: <20100616060615.GB2895@laptop.us.oracle.com>

On 06/15/2010 11:06 PM, Wengang Wang wrote:
> still the question.
> If you have sent DEREF request to the master, and the lockres became in-use
> again, then the lockres remains in the hash table and also in the purge list.
> So
> 1) If this node is the last ref, there is a possibility that the master
> purged the lockres after receiving DEREF request from this node. In this
> case, when this node does dlmlock_remote(), the lockres won't be found on the
> master. How to deal with it?
>
> 2) The lockres on this node is going to be purged again, it means it will send
> secondary DEREFs to the master. This is not good I think.
>
> A thought is setting lockres->owner to DLM_LOCK_RES_OWNER_UNKNOWN after
> sending a DEREF request againt this lockres. Also redo master reqeust
> before locking on it.
>    

The fix we are working towards is to ensure that we set
DLM_LOCK_RES_DROPPING_REF once we are determined
to purge the lockres. As in, we should not let go of the spinlock
before we have either set the flag or decided against purging
that resource.

Once the flag is set, new users looking up the resource via
dlm_get_lock_resource() will notice the flag and will then wait
for that flag to be cleared before looking up the lockres hash
again. If all goes well, the lockres will not be found (because it
has since been unhashed) and it will be forced to go thru the
full mastery process.

  parent reply	other threads:[~2010-06-17 15:06 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-16  4:43 [Ocfs2-devel] [PATCH 1/2] ocfs2 fix o2dlm dlm run purgelist Srinivas Eeda
2010-06-16  4:43 ` [Ocfs2-devel] [PATCH 2/2] ocfs2: o2dlm fix race in purge lockres and newlock (orabug 9094491) Srinivas Eeda
2010-06-18  2:11   ` Sunil Mushran
2010-06-18 16:32     ` Srinivas Eeda
2010-06-16  6:06 ` [Ocfs2-devel] [PATCH 1/2] ocfs2 fix o2dlm dlm run purgelist Wengang Wang
2010-06-17  8:53   ` Srinivas Eeda
2010-06-17 11:05     ` Wengang Wang
2010-06-17 15:06   ` Sunil Mushran [this message]
2010-06-17 16:56     ` Srinivas Eeda
2010-06-18  2:37     ` Wengang Wang
2010-06-18 16:37       ` Sunil Mushran
2010-06-21  1:40         ` Wengang Wang
2010-06-17  1:39 ` Joel Becker
2010-06-17  8:32   ` Srinivas Eeda
2010-06-17  9:08     ` Joel Becker
2010-06-17  1:44 ` Sunil Mushran
2010-06-17  6:05   ` Wengang Wang
2010-06-17  8:32   ` Joel Becker
2010-06-17  8:35     ` Srinivas Eeda
2010-06-17 14:48       ` Sunil Mushran
2010-06-17 16:55         ` Srinivas Eeda
2010-06-17 19:31           ` Sunil Mushran
2010-06-17 19:28         ` Joel Becker
2010-06-17 23:34           ` Sunil Mushran

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C1A3A05.10704@oracle.com \
    --to=sunil.mushran@oracle.com \
    --cc=ocfs2-devel@oss.oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).