All of lore.kernel.org
 help / color / mirror / Atom feed
* [Ocfs2-devel] [PATCH] ocfs2: delay migration when the lockres is in migration state
@ 2012-08-14  2:06 Xue jiufei
  2012-08-14 16:12 ` Sunil Mushran
  2012-08-15  6:42 ` Joel Becker
  0 siblings, 2 replies; 3+ messages in thread
From: Xue jiufei @ 2012-08-14  2:06 UTC (permalink / raw)
  To: ocfs2-devel

  We trigger a bug in __dlm_lockres_reserve_ast() when we parallel umount 4 nodes. The situation is as follows:
  1) Node A migrate all lockres it owned(eg. lockres A) to other nodes say node B when it umounts.  
  2) Receiving MIG_LOCKRES message from A, Node B masters the lockres A with DLM_LOCK_RES_MIGRATING state set. 
  3) Then we umount ocfs2 on node B. It also should migrate lockres A to another node, say node C. But now, DLM_LOCK_RES_MIGRATING state 
of lockers A is not cleared. Node B triggered the BUG on lockres with state DLM_LOCK_RES_MIGRATING.

Signed-off-by: Xuejiufei <xuejiufei@huawei.com>
---
 fs/ocfs2/dlm/dlmmaster.c |    4 ++++
 1 file changed, 4 insertions(+)

diff --git a/fs/ocfs2/dlm/dlmmaster.c b/fs/ocfs2/dlm/dlmmaster.c
index 005261c..6c35406 100644
--- a/fs/ocfs2/dlm/dlmmaster.c
+++ b/fs/ocfs2/dlm/dlmmaster.c
@@ -2357,6 +2357,10 @@ static int dlm_is_lockres_migrateable(struct dlm_ctxt *dlm,
 
 	assert_spin_locked(&res->spinlock);
 
+	/* delay migration when the lockres is in MIGRATING state */
+	if (res->state & DLM_LOCK_RES_MIGRATING)
+		return 0;
+
 	if (res->owner != dlm->node_num)
 		return 0;
 
-- 1.7.9.7 

^ permalink raw reply related	[flat|nested] 3+ messages in thread

* [Ocfs2-devel] [PATCH] ocfs2: delay migration when the lockres is in migration state
  2012-08-14  2:06 [Ocfs2-devel] [PATCH] ocfs2: delay migration when the lockres is in migration state Xue jiufei
@ 2012-08-14 16:12 ` Sunil Mushran
  2012-08-15  6:42 ` Joel Becker
  1 sibling, 0 replies; 3+ messages in thread
From: Sunil Mushran @ 2012-08-14 16:12 UTC (permalink / raw)
  To: ocfs2-devel

Acked-by: Sunil Mushran <sunil.mushran@gmail.com>


On Mon, Aug 13, 2012 at 7:06 PM, Xue jiufei <xuejiufei@huawei.com> wrote:

>   We trigger a bug in __dlm_lockres_reserve_ast() when we parallel umount
> 4 nodes. The situation is as follows:
>   1) Node A migrate all lockres it owned(eg. lockres A) to other nodes say
> node B when it umounts.
>   2) Receiving MIG_LOCKRES message from A, Node B masters the lockres A
> with DLM_LOCK_RES_MIGRATING state set.
>   3) Then we umount ocfs2 on node B. It also should migrate lockres A to
> another node, say node C. But now, DLM_LOCK_RES_MIGRATING state
> of lockers A is not cleared. Node B triggered the BUG on lockres with
> state DLM_LOCK_RES_MIGRATING.
>
> Signed-off-by: Xuejiufei <xuejiufei@huawei.com>
> ---
>  fs/ocfs2/dlm/dlmmaster.c |    4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/fs/ocfs2/dlm/dlmmaster.c b/fs/ocfs2/dlm/dlmmaster.c
> index 005261c..6c35406 100644
> --- a/fs/ocfs2/dlm/dlmmaster.c
> +++ b/fs/ocfs2/dlm/dlmmaster.c
> @@ -2357,6 +2357,10 @@ static int dlm_is_lockres_migrateable(struct
> dlm_ctxt *dlm,
>
>         assert_spin_locked(&res->spinlock);
>
> +       /* delay migration when the lockres is in MIGRATING state */
> +       if (res->state & DLM_LOCK_RES_MIGRATING)
> +               return 0;
> +
>         if (res->owner != dlm->node_num)
>                 return 0;
>
> -- 1.7.9.7
>
> _______________________________________________
> Ocfs2-devel mailing list
> Ocfs2-devel at oss.oracle.com
> https://oss.oracle.com/mailman/listinfo/ocfs2-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.oracle.com/pipermail/ocfs2-devel/attachments/20120814/b2c851d5/attachment.html 

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Ocfs2-devel] [PATCH] ocfs2: delay migration when the lockres is in migration state
  2012-08-14  2:06 [Ocfs2-devel] [PATCH] ocfs2: delay migration when the lockres is in migration state Xue jiufei
  2012-08-14 16:12 ` Sunil Mushran
@ 2012-08-15  6:42 ` Joel Becker
  1 sibling, 0 replies; 3+ messages in thread
From: Joel Becker @ 2012-08-15  6:42 UTC (permalink / raw)
  To: ocfs2-devel

On Tue, Aug 14, 2012 at 10:06:37AM +0800, Xue jiufei wrote:
>   We trigger a bug in __dlm_lockres_reserve_ast() when we parallel umount 4 nodes. The situation is as follows:
>   1) Node A migrate all lockres it owned(eg. lockres A) to other nodes say node B when it umounts.  
>   2) Receiving MIG_LOCKRES message from A, Node B masters the lockres A with DLM_LOCK_RES_MIGRATING state set. 
>   3) Then we umount ocfs2 on node B. It also should migrate lockres A to another node, say node C. But now, DLM_LOCK_RES_MIGRATING state 
> of lockers A is not cleared. Node B triggered the BUG on lockres with state DLM_LOCK_RES_MIGRATING.
> 
> Signed-off-by: Xuejiufei <xuejiufei@huawei.com>

This patch is now part of the fixes branch of ocfs2.git.

Joel

> ---
>  fs/ocfs2/dlm/dlmmaster.c |    4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/fs/ocfs2/dlm/dlmmaster.c b/fs/ocfs2/dlm/dlmmaster.c
> index 005261c..6c35406 100644
> --- a/fs/ocfs2/dlm/dlmmaster.c
> +++ b/fs/ocfs2/dlm/dlmmaster.c
> @@ -2357,6 +2357,10 @@ static int dlm_is_lockres_migrateable(struct dlm_ctxt *dlm,
>  
>  	assert_spin_locked(&res->spinlock);
>  
> +	/* delay migration when the lockres is in MIGRATING state */
> +	if (res->state & DLM_LOCK_RES_MIGRATING)
> +		return 0;
> +
>  	if (res->owner != dlm->node_num)
>  		return 0;
>  
> -- 1.7.9.7 

-- 

Life's Little Instruction Book #139

	"Never deprive someone of hope; it might be all they have."

			http://www.jlbec.org/
			jlbec at evilplan.org

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2012-08-15  6:42 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-08-14  2:06 [Ocfs2-devel] [PATCH] ocfs2: delay migration when the lockres is in migration state Xue jiufei
2012-08-14 16:12 ` Sunil Mushran
2012-08-15  6:42 ` Joel Becker

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.