Messages in this thread | | | Date | Mon, 05 Mar 2012 11:44:28 -0500 | From | Rik van Riel <> | Subject | Re: [PATCH 00/10] cgroups: Task counter subsystem v8 |
| |
On 02/01/2012 02:51 PM, Andrew Morton wrote: > On Wed, 1 Feb 2012 19:50:01 +0100 > Frederic Weisbecker<fweisbec@gmail.com> wrote: > >> On Wed, Feb 01, 2012 at 08:31:26AM -0800, Tejun Heo wrote: >>> On Wed, Feb 01, 2012 at 04:37:40AM +0100, Frederic Weisbecker wrote: >>>> Changes In this version: >>>> >>>> - Split 32/64 bits version of res_counter_write_u64() [1/10] >>>> Courtesy of Kirill A. Shutemov >>>> >>>> - Added Kirill's ack [8/10] >>>> >>>> - Added selftests [9/10], [10/10] >>>> >>>> Please consider for merging. At least two users want this feature: >>> >>> Has there been further discussion about this approach? IIRC, we >>> weren't sure whether this should be merged. >> >> The doubts I have noticed were: >> >> Q: Can't we rather focus on a global solution to fight forkbombs? >> >> If we can find a reliable solution that works in any case and that >> prevent from any forkbomb to impact the rest of the system then it >> may be an acceptable solution. But I'm not aware of such feature. >> >> Besides, another point in having this task counter is that we >> have a per container limit. Assuming all containers are running under >> the same user, we can protect against a container starving all others >> with a massive amount of processes close to the NR_PROC rlimit.
> What I struggle with is "is this feature useful enough to warrant > merging it"?
I have seen thunderbird create as many child processes as it could (until I hit my rlimit NR_PROC), and have seen web servers go wrong under a combination of load and buggy scripts, forking as many processes as they could.
Since we know rlimit NR_PROC is useful, having the equivalent per cgroup will be useful, too.
What we need to lose is the focus on malicious forkbombs - buggy programs are a real issue, and protecting against them is useful.
| |