cluster/cman-kernel/src sm_message.c

cluster/cman-kernel/src sm_message.c

[teigland]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL4
Changes by:	teigland@sourceware.org	2007-08-14 17:05:10

Modified files:
	cman-kernel/src: sm_message.c 

Log message:
	bz 199433: NULL pointer dereference in cman:process_messages for cmirror
	
	Adds a check for a null message, and if it finds one, prints an error
	and ignores it instead of oopsing.  This may help us get further in
	discovering the real problem.  Ignoring the null message will probably
	lead to a hang of some kind, which is better and easier to debug than
	an oopsed machine.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/cman-kernel/src/sm_message.c.diff?cvsroot=cluster&only_with_tag=RHEL4&r1=1.4.2.3&r2=1.4.2.4

cluster/cman-kernel/src sm_message.c

[teigland]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL4
Changes by:	teigland@sourceware.org	2007-10-02 20:40:48

Modified files:
	cman-kernel/src: sm_message.c 

Log message:
	bz 199433
	
	The bad pointer dereferences aren't in process_messages() as the oops
	message shows, but in another function that's been inlined.  I think
	it's likely that process_leave_request() (or possibly
	process_join_request) are getting a NULL "sev" struct and using it.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/cman-kernel/src/sm_message.c.diff?cvsroot=cluster&only_with_tag=RHEL4&r1=1.4.2.4&r2=1.4.2.5

cluster/cman-kernel/src sm_message.c

[teigland]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	STABLE
Changes by:	teigland@sourceware.org	2006-12-01 20:43:28

Modified files:
	cman-kernel/src: sm_message.c 

Log message:
	bz 217626
	The fix for bug 206193 introduced this even worse bug.
	We need to update our global_last_id locally when we create a new one.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/cman-kernel/src/sm_message.c.diff?cvsroot=cluster&only_with_tag=STABLE&r1=1.4.8.2&r2=1.4.8.3

cluster/cman-kernel/src sm_message.c

[teigland]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL4
Changes by:	teigland@sourceware.org	2006-12-01 20:40:01

Modified files:
	cman-kernel/src: sm_message.c 

Log message:
	bz 217626
	The fix for bug 206193 introduced this even worse bug.
	We need to update our global_last_id locally when we create a new one.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/cman-kernel/src/sm_message.c.diff?cvsroot=cluster&only_with_tag=RHEL4&r1=1.4.2.2&r2=1.4.2.3

cluster/cman-kernel/src sm_message.c

[teigland]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	STABLE
Changes by:	teigland@sourceware.org	2006-09-21 15:46:54

Modified files:
	cman-kernel/src: sm_message.c 

Log message:
	Before choosing a new global id for a new group, a node discovers
	what the current max group id seen by any node in the cluster is
	and picks new=max+1.  The problem is when two nodes do this in
	parallel for two different new groups (that are at the same level)
	and end up assigning the same global id to the two different groups.
	To fix this, we have a node take this max group id and add its own nodeid
	to it, so new=max+our_nodeid.  This is similar to designating some of the
	id bits to be the nodeid of the node creating the group, but that method
	would break backward compatibility.  bz 206193
	
	Also, if we reach the max value of the global id counter (0xFFFFFF),
	then print a message and refuse to go ahead forming the group.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/cman-kernel/src/sm_message.c.diff?cvsroot=cluster&only_with_tag=STABLE&r1=1.4.8.1&r2=1.4.8.2