All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sunil Mushran <sunil.mushran@oracle.com>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [PATCH 4/4] ocfs2/dlm: Make dlm_assert_master_handler() kill itself instead of the asserter
Date: Wed, 11 Feb 2009 16:19:03 -0800	[thread overview]
Message-ID: <49936AF7.50404@oracle.com> (raw)
In-Reply-To: <20090211073515.GD9512@mail.oracle.com>

Joel Becker wrote:
> 	You mean that the node asserting mastery is probably correct,
> and the node that sees a disconnect between mastery information and the
> asserter is confused?

Yes. It's empirical, ofcourse. This is not easy to trigger. Though
now I have a testcase + env in which I can trigger it more commonly.

The real issue is still there. I am working on it. The reason I want
to push this now is because there are cases when the assertee
kills off multiple asserting nodes.


> 	BUG() isn't much of a die.  Are you figuring soft lockup code
> will eventually kill this?

I've never heard of a BUG() that did not kill a node. Atleast on x86.
Are you sure about this?

  reply	other threads:[~2009-02-12  0:19 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-03 20:37 [Ocfs2-devel] [PATCH 1/4] ocfs2/dlm: Retract fix for race between purge and migrate Sunil Mushran
2009-02-03 20:37 ` [Ocfs2-devel] [PATCH 2/4] ocfs2: Cleanup the lockname print in dlmglue.c Sunil Mushran
2009-02-11  7:31   ` Joel Becker
2009-02-03 20:37 ` [Ocfs2-devel] [PATCH 3/4] ocfs2/dlm: Use ast_lock to protect ast_list Sunil Mushran
2009-02-11  7:31   ` Joel Becker
2009-02-03 20:37 ` [Ocfs2-devel] [PATCH 4/4] ocfs2/dlm: Make dlm_assert_master_handler() kill itself instead of the asserter Sunil Mushran
2009-02-11  7:35   ` Joel Becker
2009-02-12  0:19     ` Sunil Mushran [this message]
2009-02-11  7:31 ` [Ocfs2-devel] [PATCH 1/4] ocfs2/dlm: Retract fix for race between purge and migrate Joel Becker

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=49936AF7.50404@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.