summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorDavid Teigland <teigland@redhat.com>2006-08-10 22:31:23 +0400
committerSteven Whitehouse <swhiteho@redhat.com>2006-08-11 17:44:00 +0400
commitfcc8abc8d4fcdbddc383091449f3696b411aa8fb (patch)
tree281f7d7af595153904ed3458329f3c868f4e092d
parent8872187780f6104216c67e7b60c11f708b513c38 (diff)
downloadlinux-fcc8abc8d4fcdbddc383091449f3696b411aa8fb.tar.xz
[DLM] move kmap to after spin_unlock
Doing the kmap() while holding the spinlock was causing recursive spinlock problems. It seems the kmap was scheduling, although there was no warning as I'd expect. Patrick, do we need locking around the kmap? Signed-off-by: David Teigland <teigland@redhat.com> Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
-rw-r--r--fs/dlm/lowcomms.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/fs/dlm/lowcomms.c b/fs/dlm/lowcomms.c
index 7ab40422ab57..23f5ce12080b 100644
--- a/fs/dlm/lowcomms.c
+++ b/fs/dlm/lowcomms.c
@@ -934,11 +934,11 @@ static int send_to_sock(struct nodeinfo *ni)
break;
e = list_entry(ni->writequeue.next, struct writequeue_entry,
list);
- kmap(e->page);
len = e->len;
offset = e->offset;
BUG_ON(len == 0 && e->users == 0);
spin_unlock(&ni->writequeue_lock);
+ kmap(e->page);
ret = 0;
if (len) {