Re: [PATCH 0/4] forkbomb killer

From: Minchan Kim
Date: Thu Mar 24 2011 - 06:52:38 EST


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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/