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)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Feb 07 2002 - 21:00:44 EST