RE: random PIDs

RE: random PIDs

[Studierende der Universitaet des Saarlandes]

>  Finished & tested my random PID kernel/fork.c:get_pid() replacement. 
> > This one keeps track of the last N (default is 64) pids who have exited. 
> > These are then not used. So, one cannot have more then 32767 - (64 + 1 
> > (init) + 1 (idle)) = 32761 processes :o) 
> DW> Huh, should be 32701, right?! 
> 
> You're absolutely right. It must've been the victory trance :o) 
>
Have you actually tried to create lots of threads?

IIRC get_pid will loop forever if it doesn't find a free pid, and in the
worst case you can trigger that with ~11000 running threads.

And the current code can create multiple threads with the same pid (I
never tried to trigger that bug, but it seems to be possible)

--
	Manfred

RE: random PIDs

[Studierende der Universitaet des Saarlandes]

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

RE: random PIDs

[alad]

"Heusden, Folkert van" <f.v.heusden@ftr.nl> on 04/05/2001 03:45:13 PM

To:   manfred@colorfullife.com
cc:   linux-kernel@vger.kernel.org (bcc: Amol Lad/HSS)

Subject:  RE: random PIDs




>  Finished & tested my random PID kernel/fork.c:get_pid() replacement.
> > This one keeps track of the last N (default is 64) pids who have exited.

> > These are then not used. So, one cannot have more then 32767 - (64 + 1
> > (init) + 1 (idle)) = 32761 processes :o)
> DW> Huh, should be 32701, right?!
> You're absolutely right. It must've been the victory trance :o)
M> Have you actually tried to create lots of threads?

No

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?

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;

As far as my knowledge reaches, threads are cloned which triggers the
code I quoted above.

>>>> cloning of threads never means that all the clome flags are set.. AFAIK
CLONE_PID flag is used only by swpapper
process (pid- 0) during boot-up and then never used again....
-
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/

RE: random PIDs

[Heusden, Folkert van]

>  Finished & tested my random PID kernel/fork.c:get_pid() replacement. 
> > This one keeps track of the last N (default is 64) pids who have exited.

> > These are then not used. So, one cannot have more then 32767 - (64 + 1 
> > (init) + 1 (idle)) = 32761 processes :o) 
> DW> Huh, should be 32701, right?! 
> You're absolutely right. It must've been the victory trance :o) 
M> Have you actually tried to create lots of threads?

No

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?

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;

As far as my knowledge reaches, threads are cloned which triggers the
code I quoted above.

RE: random PIDs

[Heusden, Folkert van]

> Finished & tested my random PID kernel/fork.c:get_pid() replacement.
> This one keeps track of the last N (default is 64) pids who have exited.
> These are then not used. So, one cannot have more then 32767 - (64 + 1
> (init) + 1 (idle)) = 32761 processes :o)
DW> Huh, should be 32701, right?!

You're absolutely right. It must've been the victory trance :o)

Re: random PIDs

[David Weinehall]

On Wed, Apr 04, 2001 at 04:17:45PM +0200, Heusden, Folkert van wrote:
> Finished & tested my random PID kernel/fork.c:get_pid() replacement.
> This one keeps track of the last N (default is 64) pids who have exited.
> These are then not used. So, one cannot have more then 32767 - (64 + 1
> (init) + 1 (idle)) = 32761 processes :o)

Huh, should be 32701, right?!

> I know that it was all implemented before, but this patch is very small 
> and I couldn't stand the idea the fact that my last announcement was for
> a patch which didn't work at all :o)
> 
> One can find it at: http://www.vanheusden.com/Linux/kernel_patches.php3
> (or: http://www.vanheusden.com/Linux/fp-2.2.19.patch.gz but then you
> miss the list of other patches ;-])
> Patch is against kernel 2.2.19.
> 
> I did not do any performance tests, but the machine I tested it on
> (300MHz dec alpha) felt (felt?) as smooth as before :o)
> 
> 
> Folkert van Heusden
> 
> [ www.vanheusden.com ]
> 
> p.s. the patch mentioned above also raises the number of pool-words
> from 128 to 2048, adds code to do_exit which tells you if the idle
> task is killed (as in 2.4.x), and replaces
> net/core/utils.c:net_[s]random() with something which uses
> get_random_bytes().


/David
  _                                                                 _
 // David Weinehall <tao@acc.umu.se> /> Northern lights wander      \\
//  Project MCA Linux hacker        //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </

random PIDs

[Heusden, Folkert van]

Finished & tested my random PID kernel/fork.c:get_pid() replacement.
This one keeps track of the last N (default is 64) pids who have exited.
These are then not used. So, one cannot have more then 32767 - (64 + 1
(init) + 1 (idle)) = 32761 processes :o)

I know that it was all implemented before, but this patch is very small 
and I couldn't stand the idea the fact that my last announcement was for
a patch which didn't work at all :o)

One can find it at: http://www.vanheusden.com/Linux/kernel_patches.php3
(or: http://www.vanheusden.com/Linux/fp-2.2.19.patch.gz but then you
miss the list of other patches ;-])
Patch is against kernel 2.2.19.

I did not do any performance tests, but the machine I tested it on
(300MHz dec alpha) felt (felt?) as smooth as before :o)


Folkert van Heusden

[ www.vanheusden.com ]

p.s. the patch mentioned above also raises the number of pool-words
from 128 to 2048, adds code to do_exit which tells you if the idle
task is killed (as in 2.4.x), and replaces
net/core/utils.c:net_[s]random() with something which uses
get_random_bytes().