[PATCH] 2.4.18-rc2 Fix for get_pid hang

[PATCH] 2.4.18-rc2 Fix for get_pid hang

[Paul Larson]

[-- Attachment #1: Type: text/plain, Size: 277 bytes --]

Marcelo,

This was made against 2.4.18-rc2 but applies cleanly against
2.4.18-rc4.  This is a fix for a problem where if we run out of
available pids, get_pid will hang the system while it searches through
the tasks for an available pid forever.

Thanks,
Paul Larson











[-- Attachment #2: getpid.patch --]
[-- Type: text/x-patch, Size: 1652 bytes --]

diff -Naur linux-2.4.18-rc2/kernel/fork.c linux-getpid/kernel/fork.c
--- linux-2.4.18-rc2/kernel/fork.c	Wed Feb 20 09:54:39 2002
+++ linux-getpid/kernel/fork.c	Fri Feb 22 15:52:52 2002
@@ -20,6 +20,7 @@
 #include <linux/vmalloc.h>
 #include <linux/completion.h>
 #include <linux/personality.h>
+#include <linux/compiler.h>
 
 #include <asm/pgtable.h>
 #include <asm/pgalloc.h>
@@ -85,12 +86,13 @@
 {
 	static int next_safe = PID_MAX;
 	struct task_struct *p;
-	int pid;
+	int pid, beginpid;
 
 	if (flags & CLONE_PID)
 		return current->pid;
 
 	spin_lock(&lastpid_lock);
+	beginpid = last_pid;
 	if((++last_pid) & 0xffff8000) {
 		last_pid = 300;		/* Skip daemons etc. */
 		goto inside;
@@ -110,12 +112,16 @@
 						last_pid = 300;
 					next_safe = PID_MAX;
 				}
+				if(unlikely(last_pid == beginpid))
+					goto nomorepids;
 				goto repeat;
 			}
 			if(p->pid > last_pid && next_safe > p->pid)
 				next_safe = p->pid;
 			if(p->pgrp > last_pid && next_safe > p->pgrp)
 				next_safe = p->pgrp;
+			if(p->tgid > last_pid && next_safe > p->tgid)
+				next_safe = p->tgid;
 			if(p->session > last_pid && next_safe > p->session)
 				next_safe = p->session;
 		}
@@ -125,6 +131,11 @@
 	spin_unlock(&lastpid_lock);
 
 	return pid;
+
+nomorepids:
+	read_unlock(&tasklist_lock);
+	spin_unlock(&lastpid_lock);
+	return 0;
 }
 
 static inline int dup_mmap(struct mm_struct * mm)
@@ -620,6 +631,8 @@
 
 	copy_flags(clone_flags, p);
 	p->pid = get_pid(clone_flags);
+	if (p->pid == 0 && current->pid != 0)
+		goto bad_fork_cleanup;
 
 	p->run_list.next = NULL;
 	p->run_list.prev = NULL;

Re: [PATCH] 2.4.18-rc2 Fix for get_pid hang

[Alan Cox]

> This was made against 2.4.18-rc2 but applies cleanly against
> 2.4.18-rc4.  This is a fix for a problem where if we run out of
> available pids, get_pid will hang the system while it searches through
> the tasks for an available pid forever.

Wouldn't it be a much cleaner patch to limit the maximum number of processes
to less than the number of pids available. You seem to be fixing a non
problem by adding branches to the innards of a loop.

Re: [PATCH] 2.4.18-rc2 Fix for get_pid hang

[Rik van Riel]

On Sat, 23 Feb 2002, Alan Cox wrote:

> > This was made against 2.4.18-rc2 but applies cleanly against
> > 2.4.18-rc4.  This is a fix for a problem where if we run out of
> > available pids, get_pid will hang the system while it searches through
> > the tasks for an available pid forever.
>
> Wouldn't it be a much cleaner patch to limit the maximum number of
> processes to less than the number of pids available. You seem to be
> fixing a non problem by adding branches to the innards of a loop.

The problem here is that thread and process groups share
the pid namespace, so you the number of processes at which
you run out of pids varies between 10700 and 32000 ...

regards,

Rik
-- 
"Linux holds advantages over the single-vendor commercial OS"
    -- Microsoft's "Competing with Linux" document

http://www.surriel.com/		http://distro.conectiva.com/

Re: [PATCH] 2.4.18-rc2 Fix for get_pid hang

[William Lee Irwin III]

At some point in the past, Paul Larson wrote:
>> This was made against 2.4.18-rc2 but applies cleanly against
>> 2.4.18-rc4.  This is a fix for a problem where if we run out of
>> available pids, get_pid will hang the system while it searches
>> through the tasks for an available pid forever.

On Sat, Feb 23, 2002 at 12:29:47AM +0000, Alan Cox wrote:
> Wouldn't it be a much cleaner patch to limit the maximum number of
> processes to less than the number of pids available. You seem to be
> fixing a non problem by adding branches to the innards of a loop.

I've seen this one before. It seems to kick in at 11K processes, where
one would normally expect it much higher... so I'm not sure a constant
upper bound on that counter suffices. Maybe clashes of pid's with pgrp's
and sessions and tgrps are what does that, maybe it's something else.

and of course:

#include <stdgeek.h>  /* Any hope of a non-O(tasks) solution? */


Cheers,
Bill

Re: [PATCH] 2.4.18-rc2 Fix for get_pid hang

[Paul Larson]

On Fri, 2002-02-22 at 18:29, Alan Cox wrote:
> > This was made against 2.4.18-rc2 but applies cleanly against
> > 2.4.18-rc4.  This is a fix for a problem where if we run out of
> > available pids, get_pid will hang the system while it searches through
> > the tasks for an available pid forever.
> 
> Wouldn't it be a much cleaner patch to limit the maximum number of processes
> to less than the number of pids available. You seem to be fixing a non
> problem by adding branches to the innards of a loop.
> 
That was my original thought, but as Rik and WLI already pointed out, it
won't account for process groups, tgids, etc.  This isn't a purely
theoretical problem either, as we have run up against it many times.

Thanks,
Paul Larson

Re: [PATCH] 2.4.18-rc2 Fix for get_pid hang

[Alan Cox]

> > to less than the number of pids available. You seem to be fixing a non
> > problem by adding branches to the innards of a loop.
> > 
> That was my original thought, but as Rik and WLI already pointed out, it
> won't account for process groups, tgids, etc.  This isn't a purely
> theoretical problem either, as we have run up against it many times.

Agreed - and I don't have any better solutions except 32bit pid_t - which
I suspect one day we are going to need. At least the O(1) scheduler now
makes it feasible 8)