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.

Post by Erik A. Hendrik » Thu, 07 Feb 2002 05:30:13



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

 {
        static int next_safe = PID_MAX;
        struct task_struct *p;
+       int pid;

        if (flags & CLONE_PID)

                }
                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

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/