On 1039087774 seconds since the Beginning of the UNIX epoch
Jaromir Dolecek wrote:
>

>This is indeed the case. ps/top would display unreal CPU usage for
>the processes (and I belive also bogus (>100%) total CPU usage).
>There doesn't seem to be a way to give process temporal scheduling
>penalty ('nice' value sticks). So, I think the induced sleep there
>is better than messing with scheduler guts.

Hmmm, that is unfortunate.

I'd say that I still don't believe that this rather contrived case
calls for such a hack being put into the kernel, though.  I mean,
consider why we might want to do this:

	1.  to prevent malicious local DOS attack,
	2.  to prevent accidental local DOS, or
	3.  to keep up with the Joneses.

Obviously with (1) this is going to make no real difference because
something like:

	for (;;) {
		while (fork()!=-1)
			;
		for (i=0; i<SOME_BIG_NUM; i++)
			getpid();
	}

Will have a similar effect.  By defining SOME_BIG_NUM to be a few
seconds of CPU time, you can ensure that a majority of your processes
are not sleeping at any given point in time, but the outer loop
ensures that at least a few of them will try to fork in any given
second---and so you'll continue eating up process slots whenever
they become available.  You may want to randomly peturb SOME_BIG_NUM
on each iteration in case the processes get into lock-step.

In fact, I just ran a program like the above but put a sleep(1)
after each failed fork() to test it and it appeared to have exactly
the same effect as a regular fork-bomb.  As an aside I'm currently
running a fork bomb on my workstation and admittedly X is a tad
jump and periodically my mp3 player skips, but it is not like I
can't finish this email...  Granted, I'm running a fork-bomb as
myself not as root, but still the effect is so mild that it is
pretty trivial to kill even though X, wmaker, aterm, etc all have
to get time slices before I can hit ^C in the right window.

There is some credence to the argument for preventing (2), but I
can't remember the last time that I accidentally fork-bombed my
machine.  And so the machine is a little sluggish when you are
trying to fix it, well, you have two options in this case.  The
easiest one is a simple

	# renice -20 $$

which will ensure that your shell and its children are at the head
of the run queue whenever they need to be.  If you are lucky enough
to have console access and you've compile in DDB, then you can just
clean it up that way.

I can't help but think that there is a larger issue here which
should be solved in a more general way, though.  If you consider
that a random end user can cause problems by running a fork-bomb
then perhaps the answer would be to add per-user information into
the scheduler by, e.g.  keeping an additional per-user p_estcpu
and use that to ensure fair inter-user scheduling.  In that case,
a fork-bomb run as a user would not be an issue at all.

I'm not sure if I can properly address (3).  It actually has more
appeal in my mind than (1) or (2), because the ``fork-bomb'' is a
common metric that some people use to test how an OS reacts to
resource starvation.  So, by hacking around it, we can fool people
into thinking that we've actually solved the problem which is quite
good on an -advocacy front. ;-)

--
    Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/