thr3ads.net - Ocfs2 devel - [Ocfs2-devel] [Patch] fix for continuous receiving FLAG_VOTE_UPDATE

If this information is useful, please help other people find it:
Share via:

Ling, Xiaofeng

2004-Jul-05 04:27 UTC

[Ocfs2-devel] [Patch] fix for continuous receiving FLAG_VOTE_UPDATE_RETRY

It seems the inode lock system map file is not released after acquired.That
causes when another node want to acquire it,
this node found it is already holded.

--------------------------------------------------------------------------------
Index: alloc.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- alloc.c	(revision 1238)
+++ alloc.c	(working copy)
@@ -482,6 +482,21 @@
 	}
=20
 	for (i =3D 0; i < osb->max_nodes; i++) {
+		if (inode_alloc_free[i] !=3D NULL) {
+			down_write(&OCFS_I(inode_alloc_inode[i])->ip_io_sem);
+			status =3D ocfs_release_lock (osb,
+						    OCFS_LKM_EXMODE,
+						    FLAG_FILE_CREATE,
+						    NULL, inode_alloc_inode[i]);
+			up_write(&OCFS_I(inode_alloc_inode[i])->ip_io_sem);
+			if (status < 0) {
+				LOG_ERROR_STATUS (status);
+				goto finally;
+			}
+		}
+	}
+=09
+	for (i =3D 0; i < osb->max_nodes; i++) {
 		if (ext_alloc_free[i] !=3D NULL) {
 			down_write(&OCFS_I(ext_alloc_inode[i])->ip_io_sem);
 			status =3D ocfs_release_lock (osb,>-----Original Message-----
>From: ocfs2-devel-bounces@oss.oracle.com=20
>[mailto:ocfs2-devel-bounces@oss.oracle.com] On Behalf Of Ling, Xiaofeng
>Sent: 2004=C4=EA7=D4=C25=C8=D5 13:32
>To: Ocfs2-Devel
>Subject: RE: [Ocfs2-devel] [Patch] fix block when receive=20
>reply with retry--unsigned statuscause block=20
>
>I've found the FLAG_VOTE_UPDATE_RETRY is sent at nm.c line=20
>1515(svn 1238),=20
>because lockres->lock_holders>0.
>
>The reproduce step:
>Node A:
>mkdir /ocfs/aa
>Node B:
>rmdir /ocfs/aa
>Node A:
>mkdir /ocfs/bb
>...now Node A receive FLAG_VOTE_UPDATE_RETRY and always resend=20
>the CHANGE_MASTER message.
>
>=20
>
>>-----Original Message-----
>>From: ocfs2-devel-bounces@oss.oracle.com=20
>>[mailto:ocfs2-devel-bounces@oss.oracle.com] On Behalf Of=20
>Ling, Xiaofeng
>>Sent: 2004=C4=EA7=D4=C22=C8=D5 14:20
>>To: Mark Fasheh
>>Cc: Ocfs2-Devel
>>Subject: [Ocfs2-devel] [Patch] fix block when receive reply=20
>>with retry-- unsigned statuscause block=20
>>
>>the vote_stauts of ocfs_vote_obj is defined as __u32, this causes
>>"obj->vote_status < 0" always fail in
ocfs_comm_process_vote_reply.
>>When receive reply message with FLAG_VOTE_UPDATE_RETRY, the process is
>>block.
>>I have not found what causes FLAG_VOTE_UPDATE_RETRY is sent back.
>>
>>-------------------------------------------------------------------
>>Index: ocfs.h
>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>--- ocfs.h      (revision 1232)
>>+++ ocfs.h      (working copy)
>>@@ -753,7 +753,7 @@
>>        spinlock_t lock;
>>        __u32 vote_state;
>>        __u32 req_lock_type;
>>-       __u32 vote_status;
>>+       int vote_status;
>>        ocfs_node_map req_vote_map;
>>        ocfs_node_map got_vote_map;
>>        ocfs_node_map tmp_openmap;
>>_______________________________________________
>>Ocfs2-devel mailing list
>>Ocfs2-devel@oss.oracle.com
>>http://oss.oracle.com/mailman/listinfo/ocfs2-devel
>>
>>
>_______________________________________________
>Ocfs2-devel mailing list
>Ocfs2-devel@oss.oracle.com
>http://oss.oracle.com/mailman/listinfo/ocfs2-devel
>

Mark Fasheh

2004-Jul-05 12:58 UTC

head link

[Ocfs2-devel] [Patch] fix for continuous receiving FLAG_VOTE_UPDATE_RETRY

On Mon, Jul 05, 2004 at 05:27:15PM +0800, Ling, Xiaofeng
wrote:> It seems the inode lock system map file is not released after acquired.That
causes when another node want to acquire it,
> this node found it is already holded.Ahh, good catch! I saw that bug but hadn't had a chance to track it down.
It also looks like, down below that code we're not freeing the
inode_alloc_inode and the inode_alloc_free array.
>
--------------------------------------------------------------------------------
> Index: alloc.c
> ==================================================================> ---
alloc.c	(revision 1238)
> +++ alloc.c	(working copy)
> @@ -482,6 +482,21 @@
>  	}
>  
>  	for (i = 0; i < osb->max_nodes; i++) {
> +		if (inode_alloc_free[i] != NULL) {
> +			down_write(&OCFS_I(inode_alloc_inode[i])->ip_io_sem);
> +			status = ocfs_release_lock (osb,
> +						    OCFS_LKM_EXMODE,
> +						    FLAG_FILE_CREATE,
> +						    NULL, inode_alloc_inode[i]);
> +			up_write(&OCFS_I(inode_alloc_inode[i])->ip_io_sem);
> +			if (status < 0) {
> +				LOG_ERROR_STATUS (status);
> +				goto finally;
> +			}
> +		}
> +	}
> +	
> +	for (i = 0; i < osb->max_nodes; i++) {
>  		if (ext_alloc_free[i] != NULL) {
>  			down_write(&OCFS_I(ext_alloc_inode[i])->ip_io_sem);
>  			status = ocfs_release_lock (osb,Hmm, since we loop on the same conditions (i < osb->max_nodes), could you
resend with both 'if' blocks within the same 'for' loop? Also,
if you feel
like fixing the bug noted above in the same patch, that'd be just fine with
me :)
	--Mark

--
Mark Fasheh
Software Developer, Oracle Corp
mark.fasheh@oracle.com

Ling, Xiaofeng

2004-Jul-05 22:28 UTC

head link

[Ocfs2-devel] [Patch] fix for continuous receiving FLAG_VOTE_UPDATE_RETRY

=20
>-----Original Message-----
>From: Mark Fasheh [mailto:mark.fasheh@oracle.com]=20
>Sent: 2004=C4=EA7=D4=C26=C8=D5 1:58
>To: Ling, Xiaofeng
>Cc: ocfs2-devel@oss.oracle.com
>Subject: Re: [Ocfs2-devel] [Patch] fix for continuous=20
>receiving FLAG_VOTE_UPDATE_RETRY
>
>
>Hmm, since we loop on the same conditions (i <=20
>osb->max_nodes), could you
>resend with both 'if' blocks within the same 'for' loop?
Also,=20
>if you feel
>like fixing the bug noted above in the same patch, that'd be=20
>just fine with
>me :)
>	--MarkI resend the patch and also adding the free of inode_alloc_inode.
But I have a concern about combinding loop.
At acquiring, the loop is separated, that is after acquired all the
inode_alloc_inode and then
begin to acquire ext_alloc_inode. Is there any special consideration? Does
release need the
same process?

--------------------------------------------------------------------------
Index: alloc.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- alloc.c	(revision 1238)
+++ alloc.c	(working copy)
@@ -482,6 +482,19 @@
 	}
=20
 	for (i =3D 0; i < osb->max_nodes; i++) {
+		if (inode_alloc_free[i] !=3D NULL) {
+			down_write(&OCFS_I(inode_alloc_inode[i])->ip_io_sem);
+			status =3D ocfs_release_lock (osb,
+						    OCFS_LKM_EXMODE,
+						    FLAG_FILE_CREATE,
+						    NULL, inode_alloc_inode[i]);
+			up_write(&OCFS_I(inode_alloc_inode[i])->ip_io_sem);
+			if (status < 0) {
+				LOG_ERROR_STATUS (status);
+				goto finally;
+			}
+		}
+
 		if (ext_alloc_free[i] !=3D NULL) {
 			down_write(&OCFS_I(ext_alloc_inode[i])->ip_io_sem);
 			status =3D ocfs_release_lock (osb,
@@ -497,6 +510,13 @@
 	}
=20
 finally:
+	if (inode_alloc_inode) {
+		for (i =3D 0; i < osb->max_nodes; i++) {
+			if (inode_alloc_inode[i])
+				iput(inode_alloc_inode[i]);
+		}
+		kfree(inode_alloc_inode);
+	}
=20
 	if (ext_alloc_inode) {
 		for (i =3D 0; i < osb->max_nodes; i++) {

Ocfs2 devel - Jul 2004 - [Patch] fix for continuous receiving FLAG_VOTE_UPDATE_RETRY

[Ocfs2-devel] [Patch] fix for continuous receiving FLAG_VOTE_UPDATE_RETRY

[Ocfs2-devel] [Patch] fix for continuous receiving FLAG_VOTE_UPDATE_RETRY

[Ocfs2-devel] [Patch] fix for continuous receiving FLAG_VOTE_UPDATE_RETRY