Chris Murphy <lists(a)colorremedies.com> writes:
On Mon, Aug 12, 2019 at 5:47 PM Emery Berger
> For what it's worth, my research group attacked basically exactly this problem
some time ago. We built a modified Linux kernel that we called Redline that was utterly
resilient to fork bombs, malloc bombs, and so on. No process could take down the system,
much less unprivileged ones. I think some of the ideas we described back then would be
worth adopting / adapting today (the code is of course hopelessly out of date: we
published our paper on this at OSDI 2008).
I'm unable to find a concurring or dissenting opinions on this. What
kind of peer review has it received? Was it ever raised with upstream
kernel developers? What were there responses?
I have only read parts of the Redline paper so I do not know if it was
ever tried to submit this upstream.
Judging from the Redline webpage
), it appears to only ever
been implemented on i386 and nowhere else (albeit that shouldn't be hard
to fix). Furthermore it does not support NUMA, which might be a bigger
My guess is that Redline might clash with the general idea how processes
should be scheduled of upstream Linux. Redline solves the problem of
keeping interactive applications interactive even under severe memory
pressure by changing the way they are scheduled, allocated memory and
how much data they are allowed to read from disks. If an application is
classified as interactive (in contrast to best-effort tasks, which
corresponds to a process in the current Linux kernel), then it will get
a requested amount of CPU time each x ms (e.g. to be able to run at 25
fps). Something comparable is done with memory and disk usage.
This is a pretty nice approach in my opinion but it has certain
- scheduling gets more complicated
- you need additional system calls to tell the kernel which processes
are interactive (otherwise they are treated the "old" way and you gain
- you need a userspace component that has a database of interactive
tasks (with a small set of configs, e.g. how often does your process
need a chunk of the CPU time)
It could be that the kernel community would perceive that as a blocker
and would instead prefer a different and more generic solution (this is
just my personal guess). It could also very well be that no one had time
to actually upstream this, as it was an academic project (no offense
intended, I've been in academia myself and know how things
Unfortunately, Redline was developed more than a decade ago, so
upstreaming it nowadays is probably equivalent to a full rewrite, given
the kernel's development pace.