A long overdue fork-bomb defense ?! (idea + psuedocode, no patch yet)

[Robert Hailey <forkbomb@osndok.com>]

Another fork bomb thread? Didn't we decide in the 90's that the answer
was "configure process limits" or "if it was solvable surly a solution
would have been found by now"?

Somewhat continuing from:
https://lkml.org/lkml/2011/4/8/275
...but a more refined idea and psuedocode.

ASAICS I have "the ultimate solution to fork bombs"... the synopsis:
* When we run out of process table space, clear the worst offenders,
and erect a "wall" in the forkbomb's cgroup for the rest of the fork
bomb to hurriedly run into and die a horrible death.

But the efficacy of one's own ideas are hard to judge, so I would
appreciate anyone smarter than me either:
* pointing out how horribly wrong I am, or
* helping flesh out the idea into a patch or proof-of-concept that it
might be tested

... otherwise my lack of c-language skill and kernel experience might
make this languish for years to come until anything actually comes of
this.

If you interested, of course, psuedocode is here it is for your
dissection:

* http://osndok.com/pubfiles/forkbomb-patch.html

If it is more appropriate to dump the psuedocode into the email thread,
I can do that instead... I don't know what is preferred.

Thanks in advance.

--
Robert Hailey

(Non-subscriber, please CC me in responses)