cluster/dlm-kernel/src lockqueue.c

cluster/dlm-kernel/src lockqueue.c

[teigland]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL4
Changes by:	teigland@sourceware.org	2008-01-14 15:57:46

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

Log message:
	bz 351321
	
	add_to_requestqueue() can add a new message to the requestqueue
	just after process_requestqueue() checks it and determines it's
	empty.  This means dlm_recvd will spin forever in wait_requestqueue()
	waiting for the message to be removed.
	
	The same problem was found and fixed in the RHEL5 code (and then
	subsequently changed again).  This patch is the RHEL4 equivalent of the
	original RHEL5 fix.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/dlm-kernel/src/lockqueue.c.diff?cvsroot=cluster&only_with_tag=RHEL4&r1=1.37.2.11&r2=1.37.2.12

cluster/dlm-kernel/src lockqueue.c

[teigland]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL4
Changes by:	teigland@sourceware.org	2008-01-04 16:12:05

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

Log message:
	Some message gets out of place, but there's no need to panic
	the machine; just ignore it.  bz 427531

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/dlm-kernel/src/lockqueue.c.diff?cvsroot=cluster&only_with_tag=RHEL4&r1=1.37.2.10&r2=1.37.2.11

cluster/dlm-kernel/src lockqueue.c

[teigland]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL46
Changes by:	teigland@sourceware.org	2007-11-07 15:57:09

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

Log message:
	bz 349001
	
	For the entire life of the dlm, there's been an annoying issue that we've
	worked around and not "fixed" directly.  It's the source of all these
	messages:
	
	process_lockqueue_reply id 2c0224 state 0
	
	The problem that a lock master sends an async "granted" message for a
	convert request *before* actually sending the reply for the original
	convert.  The work-around is that the requesting node just takes the
	granted message as an implicit reply to the conversion and ignores the
	convert reply when it arrives later (the message above is printed when
	it gets the out-of-order reply for its convert).  Apart from the annoying
	messages, it's never been a problem.
	
	Now we've found a case where it's a real problem:
	
	1. nodeA: send convert PR->CW to nodeB
	nodeB: send granted message to nodeA
	nodeB: send convert reply to nodeA
	2. nodeA: receive granted message for conversion
	complete request, sending ast to gfs
	3. nodeA: send convert CW->EX to nodeB
	4. nodeA: receive reply for convert in step 1, which we ordinarily
	ignore, but since another convert has been sent, we mistake this
	message as the reply for the convert in step 3, and complete
	the convert request which is *not* really completed yet
	5. nodeA: send unlock to nodeB
	nodeB: complains about an unlock during a conversion
	
	The fix is to have nodeB not send a convert reply if it has already sent a
	granted message.  (We already do this for cases where the conversion is
	granted when first processing it, but we don't in cases where the grant
	is done after processing the convert.)

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/dlm-kernel/src/lockqueue.c.diff?cvsroot=cluster&only_with_tag=RHEL46&r1=1.37.2.9&r2=1.37.2.9.6.1

cluster/dlm-kernel/src lockqueue.c

[teigland]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL4
Changes by:	teigland@sourceware.org	2007-11-07 15:22:31

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

Log message:
	bz 349001
	
	For the entire life of the dlm, there's been an annoying issue that we've
	worked around and not "fixed" directly.  It's the source of all these
	messages:
	
	process_lockqueue_reply id 2c0224 state 0
	
	The problem that a lock master sends an async "granted" message for a
	convert request *before* actually sending the reply for the original
	convert.  The work-around is that the requesting node just takes the
	granted message as an implicit reply to the conversion and ignores the
	convert reply when it arrives later (the message above is printed when
	it gets the out-of-order reply for its convert).  Apart from the annoying
	messages, it's never been a problem.
	
	Now we've found a case where it's a real problem:
	
	1. nodeA: send convert PR->CW to nodeB
	nodeB: send granted message to nodeA
	nodeB: send convert reply to nodeA
	2. nodeA: receive granted message for conversion
	complete request, sending ast to gfs
	3. nodeA: send convert CW->EX to nodeB
	4. nodeA: receive reply for convert in step 1, which we ordinarily
	ignore, but since another convert has been sent, we mistake this
	message as the reply for the convert in step 3, and complete
	the convert request which is *not* really completed yet
	5. nodeA: send unlock to nodeB
	nodeB: complains about an unlock during a conversion
	
	The fix is to have nodeB not send a convert reply if it has already sent a
	granted message.  (We already do this for cases where the conversion is
	granted when first processing it, but we don't in cases where the grant
	is done after processing the convert.)

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/dlm-kernel/src/lockqueue.c.diff?cvsroot=cluster&only_with_tag=RHEL4&r1=1.37.2.9&r2=1.37.2.10

cluster/dlm-kernel/src lockqueue.c

[teigland]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL4U3
Changes by:	teigland@sourceware.org	2006-01-24 17:46:39

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

Log message:
	When GFS uses direct-io PR and CW locks are mixed together
	on a single resource.  To optimize the interaction between
	these two lock modes, GFS uses LM_FLAG_ANY to request that
	either of the modes be granted.  When the dlm carries out
	this optimization and grants a PR lock instead of a CW, or
	a CW instead of a PR, the mode is not switched on the non-
	master node.  So, for example, the lock will be requested
	in PR mode with the ALTCW flag, it will be granted on the
	master node in CW mode, but the non master (requesting)
	node will record the granted mode as PR.
	
	Fix by changing the grmode on the non-master node when we
	get ALTMODE back from the master.
	
	Fixes bz 178738

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/dlm-kernel/src/lockqueue.c.diff?cvsroot=cluster&only_with_tag=RHEL4U3&r1=1.37.2.6.10.1&r2=1.37.2.6.10.2

cluster/dlm-kernel/src lockqueue.c

[teigland]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL4U3
Changes by:	teigland@sourceware.org	2006-01-24 17:16:56

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

Log message:
	- In process_cluster_request() replace most of the assertions with an
	error message followed by ignoring the request.  There are some corner
	cases that would trigger assertions/panics when the request should
	just be ignored instead.
	
	- There's a statement to catch a corner case where a grant message
	arrives for a lock being unlocked.  We want to ignore the grant
	message, but the code was just returning instead of breaking which
	meant the in_recovery rw-semapohre wasn't being released.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/dlm-kernel/src/lockqueue.c.diff?cvsroot=cluster&only_with_tag=RHEL4U3&r1=1.37.2.6&r2=1.37.2.6.10.1

cluster/dlm-kernel/src lockqueue.c

[teigland]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL4
Changes by:	teigland@sourceware.org	2006-01-24 14:38:19

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

Log message:
	When GFS uses direct-io PR and CW locks are mixed together
	on a single resource.  To optimize the interaction between
	these two lock modes, GFS uses LM_FLAG_ANY to request that
	either of the modes be granted.  When the dlm carries out
	this optimization and grants a PR lock instead of a CW, or
	a CW instead of a PR, the mode is not switched on the non-
	master node.  So, for example, the lock will be requested
	in PR mode with the ALTCW flag, it will be granted on the
	master node in CW mode, but the non master (requesting)
	node will record the granted mode as PR.
	
	Fix by changing the grmode on the non-master node when we
	get ALTMODE back from the master.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/dlm-kernel/src/lockqueue.c.diff?cvsroot=cluster&only_with_tag=RHEL4&r1=1.37.2.8&r2=1.37.2.9

cluster/dlm-kernel/src lockqueue.c

[teigland]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	STABLE
Changes by:	teigland@sourceware.org	2006-01-23 21:58:45

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

Log message:
	When GFS uses direct-io PR and CW locks are mixed together
	on a single resource.  To optimize the interaction between
	these two lock modes, GFS uses LM_FLAG_ANY to request that
	either of the modes be granted.  When the dlm carries out
	this optimization and grants a PR lock instead of a CW, or
	a CW instead of a PR, the mode is not switched on the non-
	master node.  So, for example, the lock will be requested
	in PR mode with the ALTCW flag, it will be granted on the
	master node in CW mode, but the non master (requesting)
	node will record the granted mode as PR.
	
	Fix by changing the grmode on the non-master node when we
	get ALTMODE back from the master.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/dlm-kernel/src/lockqueue.c.diff?cvsroot=cluster&only_with_tag=STABLE&r1=1.37.2.6.6.4&r2=1.37.2.6.6.5

cluster/dlm-kernel/src lockqueue.c

[teigland]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL4
Changes by:	teigland@sourceware.org	2005-12-19 23:01:02

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

Log message:
	Remove an assertion.  Before sending a lock request we were asserting
	that the destination (from the lkb's nodeid field) matched the rsb's
	nodeid that we got from a lookup and copied to the lkb.  Given the
	right combination, the nodeid in the rsb can be invalidated by another
	failed request (and set to -1) before the assertion check.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/dlm-kernel/src/lockqueue.c.diff?cvsroot=cluster&only_with_tag=RHEL4&r1=1.37.2.7&r2=1.37.2.8

cluster/dlm-kernel/src lockqueue.c

[teigland]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	STABLE
Changes by:	teigland@sourceware.org	2005-12-19 22:55:58

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

Log message:
	Remove an assertion.  Before sending a lock request we were asserting
	that the destination (from the lkb's nodeid field) matched the rsb's
	nodeid that we got from a lookup and copied to the lkb.  Given the
	right combination, the nodeid in the rsb can be invalidated by another
	failed request (and set to -1) before the assertion check.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/dlm-kernel/src/lockqueue.c.diff?cvsroot=cluster&only_with_tag=STABLE&r1=1.37.2.6.6.3&r2=1.37.2.6.6.4

cluster/dlm-kernel/src lockqueue.c

[teigland]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL4
Changes by:	teigland@sourceware.org	2005-12-16 20:18:04

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

Log message:
	- In process_cluster_request() replace most of the assertions with an
	error message followed by ignoring the request.  There are some corner
	cases that would trigger assertions/panics when the request should
	just be ignored instead.
	
	- There's a statement to catch a corner case where a grant message
	arrives for a lock being unlocked.  We want to ignore the grant
	message, but the code was just returning instead of breaking which
	meant the in_recovery rw-semapohre wasn't being released.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/dlm-kernel/src/lockqueue.c.diff?cvsroot=cluster&only_with_tag=RHEL4&r1=1.37.2.6&r2=1.37.2.7

cluster/dlm-kernel/src lockqueue.c

[teigland]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	STABLE
Changes by:	teigland@sourceware.org	2005-12-16 16:39:57

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

Log message:
	When replacing ASSERT's with error messages one check was reversed;
	res_nodeid == 0 is the error we're checking for, res_nodeid > 0 is
	correct.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/dlm-kernel/src/lockqueue.c.diff?cvsroot=cluster&only_with_tag=STABLE&r1=1.37.2.6.6.2&r2=1.37.2.6.6.3

cluster/dlm-kernel/src lockqueue.c

[teigland]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	STABLE
Changes by:	teigland@sourceware.org	2005-12-14 23:24:55

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

Log message:
	There's a statement to catch a corner case where a grant message
	arrives for a lock being unlocked.  We want to ignore the grant
	message, but the code was just returning instead of breaking which
	meant the in_recovery rw-semapohre wasn't being released.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/dlm-kernel/src/lockqueue.c.diff?cvsroot=cluster&only_with_tag=STABLE&r1=1.37.2.6.6.1&r2=1.37.2.6.6.2

cluster/dlm-kernel/src lockqueue.c

[teigland]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	STABLE
Changes by:	teigland@sourceware.org	2005-12-14 23:20:41

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

Log message:
	In process_cluster_request() replace most of the assertions with an
	error message followed by ignoring the request.  There are some corner
	cases that would trigger assertions/panics when the request should just
	be ignored instead.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/dlm-kernel/src/lockqueue.c.diff?cvsroot=cluster&only_with_tag=STABLE&r1=1.37.2.6&r2=1.37.2.6.6.1

cluster/dlm-kernel/src lockqueue.c

[teigland]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL4
Changes by:	teigland@sourceware.org	2005-02-17 04:38:00

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

Log message:
	remove some non-critical printk's

Patches:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/cluster/dlm-kernel/src/lockqueue.c.diff?cvsroot=cluster&only_with_tag=RHEL4&r1=1.37.2.3&r2=1.37.2.4

cluster/dlm-kernel/src lockqueue.c

[teigland]

CVSROOT:	/cvs/cluster
Module name:	cluster
Changes by:	teigland@sourceware.org	2005-02-17 04:37:17

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

Log message:
	remove some non-critical printk's

Patches:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/cluster/dlm-kernel/src/lockqueue.c.diff?cvsroot=cluster&r1=1.40&r2=1.41

cluster/dlm-kernel/src lockqueue.c

[teigland]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL4
Changes by:	teigland@sourceware.org	2005-02-16 03:53:16

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

Log message:
	Blocking asts were being ignored for all locks being converted which
	resulted in some necessary basts being skipped.  In particular,
	after a failed NOQUEUE conversion, gfs could be left holding a lock
	and getting no callback for it while others were left waiting.
	
	This changes things so that a bast message is ignored if the lock is
	being converted and NOQUEUE isn't set, or if the locks is being
	unlocked.  Fixes bz 147798.

Patches:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/cluster/dlm-kernel/src/lockqueue.c.diff?cvsroot=cluster&only_with_tag=RHEL4&r1=1.37.2.2&r2=1.37.2.3

cluster/dlm-kernel/src lockqueue.c

[teigland]

CVSROOT:	/cvs/cluster
Module name:	cluster
Changes by:	teigland@sourceware.org	2005-02-16 03:52:24

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

Log message:
	Blocking asts were being ignored for all locks being converted which
	resulted in some necessary basts being skipped.  In particular,
	after a failed NOQUEUE conversion, gfs could be left holding a lock
	and getting no callback for it while others were left waiting.
	
	This changes things so that a bast message is ignored if the lock is
	being converted and NOQUEUE isn't set, or if the locks is being
	unlocked.  Fixes bz 147798.

Patches:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/cluster/dlm-kernel/src/lockqueue.c.diff?cvsroot=cluster&r1=1.39&r2=1.40