linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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>

  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).