From: Minchan Kim <minchan.kim@gmail.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"rientjes@google.com" <rientjes@google.com>,
Andrey Vagin <avagin@openvz.org>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Hugh Dickins <hughd@google.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Rik van Riel <riel@redhat.com>
Subject: Re: [PATCH 0/4] forkbomb killer
Date: Thu, 24 Mar 2011 19:52:22 +0900 [thread overview]
Message-ID: <20110324105222.GA2625@barrios-desktop> (raw)
In-Reply-To: <20110324182240.5fe56de2.kamezawa.hiroyu@jp.fujitsu.com>
Hi Kame,
On Thu, Mar 24, 2011 at 06:22:40PM +0900, KAMEZAWA Hiroyuki wrote:
>
> Cleaned up and fixed unclear logics. and removed RFC.
> Maybe this version is easy to be read.
>
>
> When we see forkbomb, it tends can be a fatal one.
>
> When A user makes a forkbomb (and sometimes reaches ulimit....
> In this case,
> - If the system is not in OOM, the admin may be able to kill all threads by
> hand..but forkbomb may be faster than pkill() by admin.
> - If the system is in OOM, the admin needs to reboot system.
> OOM killer is slow than forkbomb.
>
> So, I think forkbomb killer is appreciated. It's better than reboot.
>
> At implementing forkbomb killer, one of difficult case is like this
>
> # forkbomb(){ forkbomb|forkbomb & } ; forkbomb
>
> With this, parent tasks will exit() before the system goes under OOM.
> So, it's difficult to know the whole image of forkbomb.
>
> This patch introduce a subsystem to track mm's history and records it
> even after the task exit. (It will be flushed periodically.)
>
> I tested with several forkbomb cases and this patch seems work fine.
>
> Maybe some more 'heuristics' can be added....but I think this simple
> one works enough. Any comments are welcome.
Sorry for the late review. Recently I dont' have enough time to review patches.
Even I didn't start to review this series but I want to review this series.
It's one of my interest features. :)
But before digging in code, I would like to make a consensus to others to
need this feature. Let's Cc others.
What I think is that about "cost(frequent case) VS effectiveness(very rare case)"
as you expected. :)
1. At least, I don't meet any fork-bomb case for a few years. My primary linux usage
is just desktop and developement enviroment, NOT server. Only thing I have seen is
just ltp or intentional fork-bomb test like hackbench. AFAIR, ltp case was fixed
a few years ago. Although it happens suddenly, reboot in desktop isn't critical
as much as server's one.
2. I don't know server enviroment but I think applications executing on server
are selected by admin carefully. So virus program like fork-bomb is unlikely in there.
(Maybe I am wrong. You know than me).
If some normal program becomes fork-bomb unexpectedly, it's critical.
Admin should select application with much testing very carefully. But I don't know
the reality. :(
Of course, although he did such efforts, he could meet OOM hang situation.
In the case, he can't avoid rebooting. Sad. But for helping him, should we pay cost
in normal situation?(Again said, I didn't start looking at your code so
I can't expect the cost but at least it's more than as-is).
It could help developing many virus program and to make careless admins.
It's just my private opinion.
I don't have enough experience so I hope listen other's opinions
about generic fork-bomb killer, not memcg.
I don't intend to ignore your effort but justify your and my effort rightly.
Thanks for your effort, Kame. :)
--
Kind regards,
Minchan Kim
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-03-24 10:52 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-24 9:22 [PATCH 0/4] forkbomb killer KAMEZAWA Hiroyuki
2011-03-24 9:25 ` [PATCH 1/5] forkbomb killer config and documentation KAMEZAWA Hiroyuki
2011-03-24 9:26 ` [PATCH 2/5] forkbomb: mm tracking subsystem KAMEZAWA Hiroyuki
2011-03-24 9:28 ` [PATCH 3/5] forkbomb : mm histroy scanning and locks KAMEZAWA Hiroyuki
2011-03-24 9:29 ` [PATCH 4/5] forkbomb : periodic flushing mm history information KAMEZAWA Hiroyuki
2011-03-24 9:30 ` [PATCH 5/5] forkbomb killer KAMEZAWA Hiroyuki
2011-03-24 10:52 ` Minchan Kim [this message]
2011-03-25 0:04 ` [PATCH 0/4] " KAMEZAWA Hiroyuki
2011-03-25 2:38 ` Minchan Kim
2011-03-25 2:54 ` KAMEZAWA Hiroyuki
2011-03-25 4:05 ` Minchan Kim
2011-03-25 13:45 ` Colin Walters
2011-03-26 0:04 ` Hiroyuki Kamezawa
2011-03-26 2:34 ` Michel Lespinasse
2011-03-26 8:48 ` Hiroyuki Kamezawa
2011-03-28 16:21 ` Minchan Kim
2011-03-28 23:50 ` KAMEZAWA Hiroyuki
2011-03-29 0:24 ` Minchan Kim
2011-03-29 0:32 ` KAMEZAWA Hiroyuki
2011-03-29 1:12 ` Minchan Kim
2011-03-29 1:12 ` KAMEZAWA Hiroyuki
2011-03-29 1:27 ` Minchan Kim
2011-04-14 0:20 ` KOSAKI Motohiro
2011-04-14 0:35 ` KAMEZAWA Hiroyuki
2011-04-14 0:57 ` Minchan Kim
2011-04-14 18:13 ` David Rientjes
2011-03-28 23:46 ` Michel Lespinasse
2011-03-29 0:25 ` KAMEZAWA Hiroyuki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110324105222.GA2625@barrios-desktop \
--to=minchan.kim@gmail.com \
--cc=avagin@openvz.org \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=riel@redhat.com \
--cc=rientjes@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).