Re: forkbombing Linux distributions

[aq]

On Wed, 23 Mar 2005 13:37:38 +0100, Natanael Copa <mlists@xxxxxxxxxx> wrote:
> > > This is an example of a program in C my friends gave me that forkbombs.
> > > My previous sysctl.conf hack can't stop this, but the /etc/limits solution
> > > enables the owner of the computer to do something about it as root.
> > >
> > > int main() { while(1) { fork(); } }
> 
> I guess that "fork twice and exit" is worse than this?

you meant code like this 

int main() { while(1) { fork(); fork(); exit(); } }

 is more harmful ? I dont see why (?)

> > I find that this forkbomb doesnt always kill the machine. Trying a
> > small forkbomb, I saw that either the forkbomb process, or the parent
> > process (of forkbomb) will be killed after a while (by the kernel)
> > because of "out of memory" error. The problem is that which process
> > would be chosen to kill? (I have no idea on how kernel choose the
> > would-be-kill process).
> 
> It kills the process that reaches the limit (max proc's / out of mem)?

If so, forkbomb doesnt cause much problem like they said, since
eventually it would be killed once it reach the limit of memory. the
system will recover automatically after awhile.

> Limit the default maximum of user processes. If someone needs more, let
> the sysadmin raise it (with ulimit -u, /etc/limits, sysctl.conf
> whatever)
> 
> This should do the trick:
> 
> --- kernel/fork.c.orig  2005-03-02 08:37:48.000000000 +0100
> +++ kernel/fork.c       2005-03-21 15:22:50.000000000 +0100
> @@ -119,7 +119,7 @@
>          * value: the thread structures can take up at most half
>          * of memory.
>          */
> -       max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE);
> +       max_threads = mempages / (16 * THREAD_SIZE / PAGE_SIZE);

I dont see any advantages of halving the max_threads like this at all.
That doesnt solve the problem. You should focus elsewhere.

thank you,
aq
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/