diff options
author | Vernon Mauery <vernux@us.ibm.com> | 2006-07-01 04:35:42 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@g5.osdl.org> | 2006-07-01 09:55:57 -0700 |
commit | a99e4e413e1ab9f3c567b5519f5557afd786dc62 (patch) | |
tree | 31998183648206018452ae0c3c46aaa19724bd74 /kernel | |
parent | 9262e9149f346a5443300f8c451b8e7631e81a42 (diff) | |
download | kernel_samsung_tuna-a99e4e413e1ab9f3c567b5519f5557afd786dc62.zip kernel_samsung_tuna-a99e4e413e1ab9f3c567b5519f5557afd786dc62.tar.gz kernel_samsung_tuna-a99e4e413e1ab9f3c567b5519f5557afd786dc62.tar.bz2 |
[PATCH] pi-futex: fix mm_struct memory leak
lock_queue was getting called essentially twice in a row and was
continually incrementing the mm_count ref count, thus causing a memory
leak.
Dinakar Guniguntala provided a proper fix for the problem that simply grabs
the spinlock for the hash bucket queue rather than calling lock_queue.
The second time we do a queue_lock in futex_lock_pi, we really only need to
take the hash bucket lock.
Signed-off-by: Dinakar Guniguntala <dino@in.ibm.com>
Signed-off-by: Vernon Mauery <vernux@us.ibm.com>
Acked-by: Paul E. McKenney <paulmck@us.ibm.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'kernel')
-rw-r--r-- | kernel/futex.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/kernel/futex.c b/kernel/futex.c index 6c91f93..22aa3c1 100644 --- a/kernel/futex.c +++ b/kernel/futex.c @@ -1208,7 +1208,7 @@ static int do_futex_lock_pi(u32 __user *uaddr, int detect, int trylock, } down_read(&curr->mm->mmap_sem); - hb = queue_lock(&q, -1, NULL); + spin_lock(q.lock_ptr); /* * Got the lock. We might not be the anticipated owner if we |