Re: [PATCH 0/4] forkbomb killer

[Minchan Kim]

On Fri, Mar 25, 2011 at 9:04 AM, KAMEZAWA Hiroyuki
<kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote:
> On Thu, 24 Mar 2011 19:52:22 +0900
> Minchan Kim <minchan.kim@xxxxxxxxx> wrote:
>
>> Hi Kame,
>>
> Hi.
>
>> On Thu, Mar 24, 2011 at 06:22:40PM +0900, KAMEZAWA Hiroyuki wrote:
>> >
>> > 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.
>>
>
> Personally, I've met forkbombs several times by typing "make -j" .....by mistake.
>
> I met a forkbomb on production system by buggy script, once.
> That happens because
> Â1. $PATH includes "."
> Â2. a programmer write a scirpt "date" and call "date" in the script.
>
> Maybe this is a one of typical case of forkbomb. I needed to dig crashdump to find
> fragile of page-caches and see what happens...But, I guess, if appearent forkbomb
> happens, the issue will not be sent to my team because we're 2nd line support team
> and 1st line should block it ;).
>
> So, I'm not sure how many forkbombs happens in server world in a year. But I guess
> forkbomb still happens in many development systems because there is no guard
> against it.
>
>
>> 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. :(
>>
>
> Yes, admin selects applications carefully. There is no 100% protection by human's hand.
>
>
>> 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.
>>
>
> To me, the fact "the system _can_ be broken by a normal user program" is the most
> terrible thing. With Andrey's case or make -j, a user doesn't need to be an admin.
> I believe it's worth to pay costs.
> (and I made this function configurable and can be turned off by sysfs.)
>
> And while testing Andrey's case, I used KVM finaly becasue cost of rebooting was small.
> My development server is on other building and I need to push server's button
> to reboot it when forkbomb happens ;)
> In some environement, cost of rebooting is not small even if it's a development system.
>

Forkbomb is very rare case in normal situation but if it happens, the
cost like reboot would be big. So we need the such facility. I agree.
(But I don't know why others don't have a interest if it is important
task. Maybe they are so busy due to rc1)
Just a concern is cost.
The approach is we can enhance your approach to minimize the cost but
apparently it would have a limitation.

Other approach is we can provide new rescue facility.
What I have thought is new sysrq about killing fork-bomb.

If we execute the new sysrq, the kernel freezes all tasks so forkbomb
can't execute any more and kernel ready to receive the command to show
the system state. Admin can investigate which is fork-bomb and then he
kill the tasks. At last, admin restarts all processes with new sysrq
and processes which received SIGKILL start to die.

This approach offloads kernel's heuristic forkbomb detection to admin
and avoid runtime cost in normal situation.
I don't have any code to implement above the concept so it might be ridiculous.

What do you think about it?

>
> Thanks,
> -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/