Message-ID: <3ACC41C9.4BE4DD0A@stud.uni-saarland.de>
Date: Thu, 05 Apr 2001 09:58:33 +0000
From: Studierende der Universitaet des Saarlandes 
	<masp0008@stud.uni-sb.de>
Reply-To: manfred@colorfullife.com
Organization: Studierende Universitaet des Saarlandes
MIME-Version: 1.0
To: f.v.heusden@ftr.nl
CC: linux-kernel@vger.kernel.org
Subject: RE: random PIDs
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org

> 
> M> IIRC get_pid will loop forever if it doesn't find a free pid, and in the 
> M> worst case you can trigger that with ~11000 running threads. 
> 
> Ah, ok. But why would you have 11.000 running threads? 

Denial of Service attack. 11000 processes and the kernel locks up hard,
regardless of the amount of memory.(sane ulimits prevent that)

> M> And the current code can create multiple threads with the same pid (I 
> M> never tried to trigger that bug, but it seems to be possible) 
>
> mine will do that too: 
> 
>         if (flags & CLONE_PID) 
>                 return current->pid; 
> 
CLONE_PID is a special flag for the boot process, normal processes can't
set that flag. (first line of do_fork() returns -EPERM)

Even without CLONE_PID two threads can get the same pid:
get_pid searches for a new pid by scanning though the task list.
But the caller of get_pid doesn't atomically add the new value to the
task list.
If copy_fs, copy_files, copy_mm sleep, then a second thread could get
the same pid.
It's only possible if nearly all pid values are used up, so it's not a
problem that must be fixed immediately.

--
	Manfred
-
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/