Commit ef0c2bb0 authored Mar 28, 2007 by David Teigland Committed by Steven Whitehouse May 01, 2007

[DLM] overlapping cancel and unlock



Full cancel and force-unlock support.  In the past, cancel and force-unlock
wouldn't work if there was another operation in progress on the lock.  Now,
both cancel and unlock-force can overlap an operation on a lock, meaning there
may be 2 or 3 operations in progress on a lock in parallel.  This support is
important not only because cancel and force-unlock are explicit operations
that an app can use, but both are used implicitly when a process exits while
holding locks.

Summary of changes:

- add-to and remove-from waiters functions were rewritten to handle situations
  with more than one remote operation outstanding on a lock

- validate_unlock_args detects when an overlapping cancel/unlock-force
  can be sent and when it needs to be delayed until a request/lookup
  reply is received

- processing request/lookup replies detects when cancel/unlock-force
  occured during the op, and carries out the delayed cancel/unlock-force

- manipulation of the "waiters" (remote operation) state of a lock moved under
  the standard rsb mutex that protects all the other lock state

- the two recovery routines related to locks on the waiters list changed
  according to the way lkb's are now locked before accessing waiters state

- waiters recovery detects when lkb's being recovered have overlapping
  cancel/unlock-force, and may not recover such locks

- revert_lock (cancel) returns a value to distinguish cases where it did
  nothing vs cases where it actually did a cancel; the cancel completion ast
  should only be done when cancel did something

- orphaned locks put on new list so they can be found later for purging

- cancel must be called on a lock when making it an orphan

- flag user locks (ENDOFLIFE) at the end of their useful life (to the
  application) so we can return an error for any further cancel/unlock-force

- we weren't setting COMP/BAST ast flags if one was already set, so we'd lose
  either a completion or blocking ast

- clear an unread bast on a lock that's become unlocked

Signed-off-by: David Teigland <teigland@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>

parent 03206727

fs/dlm/dlm_internal.h

+8 −2

Original line number	Diff line number	Diff line
		@@ -2,7 +2,7 @@
		*******************************************************************************
		**
		** Copyright (C) Sistina Software, Inc. 1997-2003 All rights reserved.
		** Copyright (C) 2004-2005 Red Hat, Inc. All rights reserved.
		** Copyright (C) 2004-2007 Red Hat, Inc. All rights reserved.
		**
		** This copyrighted material is made available to anyone wishing to use,
		** modify, copy, or redistribute it subject to the terms and conditions
		@@ -210,6 +210,9 @@ struct dlm_args {
		#define DLM_IFL_MSTCPY 0x00010000
		#define DLM_IFL_RESEND 0x00020000
		#define DLM_IFL_DEAD 0x00040000
		#define DLM_IFL_OVERLAP_UNLOCK 0x00080000
		#define DLM_IFL_OVERLAP_CANCEL 0x00100000
		#define DLM_IFL_ENDOFLIFE 0x00200000
		#define DLM_IFL_USER 0x00000001
		#define DLM_IFL_ORPHAN 0x00000002

		@@ -230,8 +233,8 @@ struct dlm_lkb {
		int8_t lkb_grmode; /* granted lock mode */
		int8_t lkb_bastmode; /* requested mode */
		int8_t lkb_highbast; /* highest mode bast sent for */

		int8_t lkb_wait_type; /* type of reply waiting for */
		int8_t lkb_wait_count;
		int8_t lkb_ast_type; /* type of ast queued for */

		struct list_head lkb_idtbl_list; /* lockspace lkbtbl */
		@@ -440,6 +443,9 @@ struct dlm_ls {
		struct mutex ls_waiters_mutex;
		struct list_head ls_waiters; /* lkbs needing a reply */

		struct mutex ls_orphans_mutex;
		struct list_head ls_orphans;

		struct list_head ls_nodes; /* current nodes in ls */
		struct list_head ls_nodes_gone; /* dead node list, recovery */
		int ls_num_nodes; /* number of nodes in ls */