On Friday 23 June 2006 13:56, Vernon Mauery wrote: > On Sunday 18 June 2006 00:06, Ingo Molnar wrote: > > i have released the 2.6.17-rt1 tree, which can be downloaded from the > > usual place: > > I was given a test case to run that seemed to cause the machine to run the > OOM-killer after a bunch of iterations. The test was run like: > > $ for ((i=0;i<50000;i++)); do ./test; done > > and somewhere in there, the LowFree would drop very low and the test and > the bash shell running it would get killed. And then since that didn't > free up much memory, the machine would become very unresponsive and would > have to be rebooted. I found the problem -- it was in the PI futex code -- lock_queue was getting called essentially twice in a row and was continually incrementing the mm_count ref count, thus causing the memory leak. Not completely understanding all the intricacies of the PI futex code, I just suggested to no make the second call to lock_queue (not realizing __queue_me unlocks the queue). Dinakar Guniguntala provided a proper fix for the problem that simply grabs the spinlock for the hash bucket queue rather than calling lock_queue. His fix is below and applies to 2.6.17-rt4. Attached is a test case I wrote to reproduce the problem. --Vernon 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 Signed-off-by: Vernon Mauery Acked-by: Paul E. McKenney Index: linux-2.6.17-rt4/kernel/futex.c =================================================================== --- a/kernel/futex.c 2006-06-30 04:39:29.000000000 -0700 +++ b/kernel/futex.c 2006-06-30 04:46:52.000000000 -0700 @@ -1269,7 +1269,7 @@ } 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