summaryrefslogtreecommitdiffstats
path: root/fs/dlm/requestqueue.c
Commit message (Collapse)AuthorAgeFilesLines
* dlm: use more NOFS allocationDavid Teigland2009-05-151-1/+1
| | | | | | | | | Change some GFP_KERNEL allocations to use either GFP_NOFS or ls_allocation (when available) which the fs sets to GFP_NOFS. The point is to prevent allocations from going back into the cluster fs in places where that might lead to deadlock. Signed-off-by: David Teigland <teigland@redhat.com>
* dlm: use proper C for dlm/requestqueue stuff (and fix alignment bug)Al Viro2008-02-041-6/+6
| | | | | | | | | | | a) don't cast the pointer to dlm_header *, we use it as dlm_message * anyway. b) we copy the message into a queue element, then pass the pointer to copy to dlm_receive_message_saved(); declare it properly to make sure that we have the right alignment. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: David Teigland <teigland@redhat.com>
* [DLM] block dlm_recv in recovery transitionDavid Teigland2007-10-101-34/+24
| | | | | | | | | | | | | | | | | | | | | | | | Introduce a per-lockspace rwsem that's held in read mode by dlm_recv threads while working in the dlm. This allows dlm_recv activity to be suspended when the lockspace transitions to, from and between recovery cycles. The specific bug prompting this change is one where an in-progress recovery cycle is aborted by a new recovery cycle. While dlm_recv was processing a recovery message, the recovery cycle was aborted and dlm_recoverd began cleaning up. dlm_recv decremented recover_locks_count on an rsb after dlm_recoverd had reset it to zero. This is fixed by suspending dlm_recv (taking write lock on the rwsem) before aborting the current recovery. The transitions to/from normal and recovery modes are simplified by using this new ability to block dlm_recv. The switch from normal to recovery mode means dlm_recv goes from processing locking messages, to saving them for later, and vice versa. Races are avoided by blocking dlm_recv when setting the flag that switches between modes. Signed-off-by: David Teigland <teigland@redhat.com> Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
* [DLM] fix add_requestqueue checking nodes listDavid Teigland2006-11-301-3/+4
| | | | | | | | | | | | | | | | | Requests that arrive after recovery has started are saved in the requestqueue and processed after recovery is done. Some of these requests are purged during recovery if they are from nodes that have been removed. We move the purging of the requests (dlm_purge_requestqueue) to later in the recovery sequence which allows the routine saving requests (dlm_add_requestqueue) to avoid filtering out requests by nodeid since the same will be done by the purge. The current code has add_requestqueue filtering by nodeid but doesn't hold any locks when accessing the list of current nodes. This also means that we need to call the purge routine when the lockspace is being shut down since the add routine will not be rejecting requests itself any more. Signed-off-by: David Teigland <teigland@redhat.com> Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
* [DLM] fix requestqueue raceDavid Teigland2006-11-301-4/+17
| | | | | | | | | | | | | | | Red Hat BZ 211914 There's a race between dlm_recoverd (1) enabling locking and (2) clearing out the requestqueue, and dlm_recvd (1) checking if locking is enabled and (2) adding a message to the requestqueue. An order of recoverd(1), recvd(1), recvd(2), recoverd(2) will result in a message being left on the requestqueue. The fix is to have dlm_recvd check if dlm_recoverd has enabled locking after taking the mutex for the requestqueue and if it has processing the message instead of queueing it. Signed-off-by: David Teigland <teigland@redhat.com> Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
* [DLM] Update DLM to the latest patch levelDavid Teigland2006-01-201-13/+13
| | | | | Signed-off-by: David Teigland <teigland@redhat.com> Signed-off-by: Steve Whitehouse <swhiteho@redhat.com>
* [DLM] The core of the DLM for GFS2/CLVMDavid Teigland2006-01-181-0/+184
This is the core of the distributed lock manager which is required to use GFS2 as a cluster filesystem. It is also used by CLVM and can be used as a standalone lock manager independantly of either of these two projects. It implements VAX-style locking modes. Signed-off-by: David Teigland <teigland@redhat.com> Signed-off-by: Steve Whitehouse <swhiteho@redhat.com>