Linux 2.4.17,2.5.3 process ID allocator isn't quite SMP safe.

Linux 2.4.17,2.5.3 process ID allocator isn't quite SMP safe.

[Erik A. Hendriks]

The get_pid function in kernel/fork.c returns the value of last_pid
after releasing the lock protecting it.  On SMPs, I have observed two
processes occasionally being assigned the same process ID as a result.

I'm pretty sure the sequence of events looks like this: The first
process releases the lock after coming up with a suitable pid (stored
in last_pid).  Then after it releases the lock but before it does the
return (IRQ or something happens here to create delay?) another
processor comes a long and updates it.  Then get_pid returns the value
of last_pid which is now the pid chosen by the other process.

Attached below is a little patch to fix it.

- Erik

--- linux-2.4.17/kernel/fork.c.orig	Mon Feb  4 14:53:31 2002
+++ linux-2.4.17/kernel/fork.c	Mon Feb  4 14:53:53 2002
@@ -85,6 +85,7 @@
 {
 	static int next_safe = PID_MAX;
 	struct task_struct *p;
+	int pid;
 
 	if (flags & CLONE_PID)
 		return current->pid;
@@ -120,9 +121,10 @@
 		}
 		read_unlock(&tasklist_lock);
 	}
+	pid = last_pid;
 	spin_unlock(&lastpid_lock);
 
-	return last_pid;
+	return pid;
 }
 
 static inline int dup_mmap(struct mm_struct * mm)