From: Vernon Mauery <vernux@us.ibm.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: linux-kernel@vger.kernel.org
Subject: [PATCH -RT]Re: 2.6.17-rt1 - mm_struct leak
Date: Fri, 30 Jun 2006 09:02:32 -0700 [thread overview]
Message-ID: <200606300902.33017.vernux@us.ibm.com> (raw)
In-Reply-To: <200606231356.56267.vernux@us.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1950 bytes --]
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 <dino@in.ibm.com>
Signed-off-by: Vernon Mauery <vernux@us.ibm.com>
Acked-by: Paul E. McKenney <paulmck@us.ibm.com>
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
[-- Attachment #2: mm_leak.c --]
[-- Type: text/plain, Size: 4138 bytes --]
/* Filename: mm_leak.c
* Author: Vernon Mauery <vernux@us.ibm.com>
* Description: force a kernel memory leak using pi mutexes
* Compilation: gcc mm_leak.c -lm -L/usr/lib/nptl -lpthread -lrt -D_GNU_SOURCE -I/usr/include/nptl -o mm_leak
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*
* Copyright (C) IBM Corporation, 2006
*
* 2006-May-3: Initial version by Darren Hart <dvhltc@us.ibm.com>
* 2006-May-4: Timing fixes reported by Vernon Mauery <vernux@us.ibm.com>
* 2006-May-4: Made the med prio threads RT by Darren Hart <dvhltc@us.ibm.com>
* 2006-May-5: Modified to use flagging by Vernon Mauery <vernux@us.ibm.com>
*/
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <pthread.h>
#include <sched.h>
#define HIGH_PRIO 15
#define ITERATIONS 100
static int count = 0;
static pthread_mutex_t pi_mutex;
struct thread {
pthread_t pthread;
pthread_attr_t attr;
};
int create_fifo_thread(struct thread *thread, void*(*func)(void*), void *arg, int prio)
{
struct sched_param param;
param.sched_priority = sched_get_priority_min(SCHED_FIFO) + prio;
pthread_attr_init(&thread->attr);
pthread_attr_setinheritsched(&thread->attr, PTHREAD_EXPLICIT_SCHED);
pthread_attr_setschedparam(&thread->attr, ¶m);
pthread_attr_setschedpolicy(&thread->attr, SCHED_FIFO);
if (pthread_create(&thread->pthread, &thread->attr, func, (void*)arg)) {
perror("pthread_create failed");
return 1;
}
pthread_attr_destroy(&thread->attr);
return 0;
}
void init_pi_mutex(pthread_mutex_t *m, int use_pi)
{
pthread_mutexattr_t attr;
int ret;
int protocol;
if (pthread_mutexattr_init(&attr) != 0) {
printf("Failed to init mutexattr\n");
}
if (use_pi) {
if (pthread_mutexattr_setprotocol(&attr, PTHREAD_PRIO_INHERIT) != 0) {
printf("Can't set protocol prio inherit\n");
}
}
if (pthread_mutexattr_getprotocol(&attr, &protocol) != 0) {
printf("Can't get mutexattr protocol\n");
}
if ((ret = pthread_mutex_init(m, &attr)) != 0) {
printf("Failed to init mutex: %d\n", ret);
}
/* FIXME: does any of this need to be destroyed ? */
}
#define THREADS 2
void *thread_one(void *arg)
{
int iterations = (int)arg;
while (count < iterations) {
while (1) {
pthread_mutex_lock(&pi_mutex);
if (count % THREADS == 1)
break;
pthread_mutex_unlock(&pi_mutex);
usleep(10);
}
printf("1"); fflush(NULL);
count++;
pthread_mutex_unlock(&pi_mutex);
}
return NULL;
}
void *thread_zero(void *arg) {
int iterations = (int)arg;
while (count < iterations) {
while (1) {
pthread_mutex_lock(&pi_mutex);
if (count % THREADS == 0)
break;
pthread_mutex_unlock(&pi_mutex);
usleep(1);
}
printf("0"); fflush(NULL);
count++;
pthread_mutex_unlock(&pi_mutex);
}
return NULL;
}
int main(int argc, char *argv[])
{
struct thread one;
int iterations = ITERATIONS;
int pi = 1, c;
while ((c=getopt(argc, argv, "i:ph")) >= 0) {
if (c == 'i') {
iterations = atoi(optarg);
} else if (c == 'p') {
pi = 0;
} else {
printf("usage: %s [-i iterations] [-p] [-h]\n", argv[0]);
printf("\t -i iterations\n");
printf("\t -p -- do not use pi mutexes\n");
printf("\t -h -- print this message\n");
exit(0);
}
}
/* creating the mutex as a PI mutex causes a kernel memory leak */
init_pi_mutex(&pi_mutex, pi);
create_fifo_thread(&one, thread_one, (void*)iterations, HIGH_PRIO);
thread_zero((void*)iterations);
pthread_join(one.pthread, NULL);
printf("\n");
return 0;
}
prev parent reply other threads:[~2006-06-30 16:02 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-18 7:06 2.6.17-rt1 Ingo Molnar
2006-06-18 16:13 ` 2.6.17-rt1 Michal Piotrowski
[not found] ` <Pine.LNX.4.64.0606201656230.11643@localhost.localdomain>
2006-06-20 15:13 ` Why can't I set the priority of softirq-hrt? (Re: 2.6.17-rt1) Thomas Gleixner
2006-06-20 17:09 ` Esben Nielsen
2006-06-20 16:35 ` Thomas Gleixner
2006-06-20 21:16 ` Esben Nielsen
2006-06-20 20:35 ` Thomas Gleixner
2006-06-20 23:19 ` Esben Nielsen
2006-06-20 16:39 ` Steven Rostedt
2006-06-20 18:12 ` Esben Nielsen
2006-06-20 17:21 ` Thomas Gleixner
2006-06-20 21:26 ` Esben Nielsen
2006-06-20 20:51 ` Thomas Gleixner
2006-06-21 8:20 ` Steven Rostedt
2006-06-21 11:05 ` Esben Nielsen
2006-06-21 15:43 ` Esben Nielsen
2006-06-21 15:21 ` Steven Rostedt
2006-06-21 16:37 ` Esben Nielsen
2006-06-21 15:51 ` Steven Rostedt
2006-06-21 17:14 ` Esben Nielsen
2006-06-21 16:26 ` Thomas Gleixner
2006-06-21 18:30 ` Ingo Molnar
2006-06-22 10:28 ` Esben Nielsen
2006-06-21 21:29 ` Esben Nielsen
2006-06-21 20:33 ` Thomas Gleixner
2006-06-21 23:35 ` Esben Nielsen
2006-06-22 7:06 ` Thomas Gleixner
2006-06-22 10:32 ` Esben Nielsen
2006-06-22 13:33 ` Steven Rostedt
2006-06-22 13:45 ` Steven Rostedt
2006-06-22 14:20 ` Thomas Gleixner
2006-06-22 14:23 ` Steven Rostedt
2006-06-22 14:26 ` Thomas Gleixner
2006-06-22 18:06 ` Esben Nielsen
2006-06-22 18:05 ` Thomas Gleixner
2006-06-23 11:23 ` Esben Nielsen
2006-06-23 11:06 ` Steven Rostedt
2006-07-03 11:48 ` Esben Nielsen
2006-06-21 8:13 ` Steven Rostedt
2006-06-21 11:03 ` Esben Nielsen
2006-06-22 0:57 ` 2.6.17-rt1 Lee Revell
2006-06-22 2:51 ` More weird latency trace output (was Re: 2.6.17-rt1) Lee Revell
2006-06-23 1:24 ` Lee Revell
2006-06-24 22:15 ` Lee Revell
2006-06-24 22:12 ` Ingo Molnar
2006-06-24 22:31 ` Lee Revell
2006-06-24 23:49 ` Lee Revell
2006-06-23 20:56 ` 2.6.17-rt1 - mm_struct leak Vernon Mauery
2006-06-24 9:24 ` Mark Hounschell
2006-06-24 9:32 ` Mark Hounschell
2006-06-30 16:02 ` Vernon Mauery [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200606300902.33017.vernux@us.ibm.com \
--to=vernux@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.