Messages in this thread |  | | Date | Sun, 9 Apr 2017 17:04:04 -0500 | From | Robert Hailey <> | Subject | A long overdue fork-bomb defense ?! (idea + psuedocode, no patch yet) |
| |
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)
|  |