From mboxrd@z Thu Jan  1 00:00:00 1970
From: teigland@sourceware.org <teigland@sourceware.org>
Date: 18 Sep 2006 17:00:24 -0000
Subject: [Cluster-devel] cluster/dlm-kernel/src lkb.c
Message-ID: <20060918170024.24692.qmail@sourceware.org>
List-Id: <cluster-devel.redhat.com>
To: cluster-devel.redhat.com
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL4U4
Changes by:	teigland at sourceware.org	2006-09-18 17:00:23

Modified files:
	dlm-kernel/src : lkb.c 

Log message:
	Don't create lkids of 0.  When the lkid counter for bucket 0 of the
	hash table rolls over (it's uint16), we'd get a lkid of zero and
	assign it to the new lkb.  lock_dlm would be confused by a zero lkid
	and use some other, incorrect value as the lkid which would lead to
	a dlm error which would lead to a lock_dlm/gfs panic.
	this should fix bz 199673
	it may also fix bz 172944

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/dlm-kernel/src/lkb.c.diff?cvsroot=cluster&only_with_tag=RHEL4U4&r1=1.3.2.1&r2=1.3.2.1.12.1

--- cluster/dlm-kernel/src/Attic/lkb.c	2005/01/18 10:46:52	1.3.2.1
+++ cluster/dlm-kernel/src/Attic/lkb.c	2006/09/18 17:00:23	1.3.2.1.12.1
@@ -79,6 +79,11 @@
 
 	lkid = bucket | (ls->ls_lkbtbl[bucket].counter++ << 16);
 
+	if (!lkid) {
+		write_unlock(&ls->ls_lkbtbl[bucket].lock);
+		goto retry;
+	}
+
 	if (__find_lock_by_id(ls, lkid)) {
 		write_unlock(&ls->ls_lkbtbl[bucket].lock);
 		goto retry;