All of lore.kernel.org
 help / color / mirror / Atom feed
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, &param);
	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;
}

      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.