Date:	Thu, 24 Mar 2011 19:52:22 +0900
From:	Minchan Kim <minchan.kim@...il.com>
To:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
Cc:	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"rientjes@...gle.com" <rientjes@...gle.com>,
	Andrey Vagin <avagin@...nvz.org>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Hugh Dickins <hughd@...gle.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Rik van Riel <riel@...hat.com>
Subject: Re: [PATCH 0/4] forkbomb killer

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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists