[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56424B83.2080504@gmail.com>
Date: Tue, 10 Nov 2015 14:54:43 -0500
From: Austin S Hemmelgarn <ahferroin7@...il.com>
To: Parav Pandit <pandit.parav@...il.com>
Cc: Aleksa Sarai <cyphar@...har.com>, Max Kellermann <mk@...all.com>,
Tejun Heo <tj@...nel.org>, cgroups@...r.kernel.org,
lizefan@...wei.com, Johannes Weiner <hannes@...xchg.org>,
max@...mpel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] cgroup_pids: add fork limit
On 2015-11-10 11:19, Parav Pandit wrote:
> On Tue, Nov 10, 2015 at 9:28 PM, Austin S Hemmelgarn
> <ahferroin7@...il.com> wrote:
>> On 2015-11-10 10:25, Aleksa Sarai wrote:
>>>
>>> Processes don't "use up resources" after they've died and been freed
>>> (which is dealt with inside PIDs). Yes, lots of small processes that
>>> die quickly could (in principle) make hard work for the scheduler, but
>>> I don't see how "time spent scheduling in general" is a resource...
>>> Fork bombs aren't bad because they cause a lot of fork()s, they're bad
>>> because the *create a bunch of processes that use up memory*, which
>>> happens because they call fork() a bunch of times and **don't
>>> exit()**.
>>
>> While I'm indifferent about the patch, I would like to point out that
>> fork-bombs are also bad because they eat _a lot_ of processor time, and I've
>> seen ones designed to bring a system to it's knees just by saturating the
>> processor with calls to fork() (which is as slow as or slower than stat() on
>> many commodity systems, setting up the various structures for a new process
>> is an expensive operation) and clogging up the scheduler.
>
> Isn't cpu cgroup helpful there to limit it?
Possibly, I don't know the specifics of how it handles stuff executing
in a context technically outside of a process on behalf of that process.
I'm almost 100% certain that there is no sane way it can account and
limit time spent in the scheduler because a process is spawning lots of
children.
> Are you saying time spent by scheduler is more that actually affects
> the scheduling of processes of other threads?
In some cases yes, although this is very dependent on the system itself
(for example, if you have a really low /proc/sys/pids_max, it will never
be an issue, but that will also make it easier for a fork-bomb to make
your system unusable). The scheduler on Linux is comparatively fast for
how feature rich it is, but it still slows down as you have more and
more processes to schedule. If you have a lot of RAM proportionate to
your processing power (as in, multiple GB on a processor running at only
a few MHz, and yes such systems do exist), then the scheduling overhead
is much more significant than the memory overhead. Even without such a
situation, it's fully possible to weigh down the system with overhead
from the kernel. As an example, a on a Raspberry Pi (single core 700MHz
ARM11stj-z CPU, 512MB of RAM), you can spawn a few hundred processes
each just sitting on an interval timer set so that every time the
scheduler runs, at least 10% of them are runnable (and I've seen
fork-bombs that do this), and you will render the system unusable not
because of memory consumption, but the scheduling and timer overhead.
> If so, could you share little more insight on how that time measure
> outside of the cpu's cgroup cycles? Just so that its helpful to wider
> audience.
Well, there are a number of things that I can think of that the kernel
does on behalf of processes that can consume processor time that isn't
trivial to account:
* Updating timers on behalf of userspace processes (itimers or similar).
* Sending certain kernel generated signals to processes (that is,
stuff generated by the kernel like SIGFPE, SIGSEGV, and so forth).
* Queuing events from dnotify/inotify/fanotify.
* TLB misses, page faults, and swapping.
* Setting up new processes prior to them actually running.
* Scheduling.
All of these are things that fork-bombs can and (other than TLB misses)
do exploit to bring a system down, and the cpu cgroup is by no means a
magic bullet to handle this.
Download attachment "smime.p7s" of type "application/pkcs7-signature" (3019 bytes)
Powered by blists - more mailing lists