Re: [PATCH 0/4] forkbomb killer

[Minchan Kim]

On Sat, Mar 26, 2011 at 05:48:45PM +0900, Hiroyuki Kamezawa wrote:
> 2011/3/26 Michel Lespinasse <walken@xxxxxxxxxx>:
> > On Fri, Mar 25, 2011 at 01:05:50PM +0900, Minchan Kim wrote:
> >> Okay. Each approach has a pros and cons and at least, now anyone
> >> doesn't provide any method and comments but I agree it is needed(ex,
> >> careless and lazy admin could need it strongly). Let us wait a little
> >> bit more. Maybe google guys or redhat/suse guys would have a opinion.
> >
> > I haven't heard of fork bombs being an issue for us (and it's not been
> > for me on my desktop, either).
> >
> > Also, I want to point out that there is a classical userspace solution
> > for this, as implemented by killall5 for example. One can do
> > kill(-1, SIGSTOP) to stop all processes that they can send
> > signals to (except for init and itself). Target processes
> > can never catch or ignore the SIGSTOP. This stops the fork bomb
> > from causing further damage. Then, one can look at the process
> > tree and do whatever is appropriate - including killing by uid,
> > by cgroup or whatever policies one wants to implement in userspace.
> > Finally, the remaining processes can be restarted using SIGCONT.
> >
> 
> Can that solution work even under OOM situation without new login/commands ?
> Please show us your solution, how to avoid Andrey's Bomb  with your way.
> Then, we can add Documentation, at least. Or you can show us your tool.
> 
> Maybe it is....
> - running as a daemon. (because it has to lock its work memory before OOM.)
> - mlockall its own memory to work under OOM.
> - It can show process tree of users/admin or do all in automatic way
> with user's policy.
> - tell us which process is guilty.
> - wakes up automatically when OOM happens.....IOW, OOM should have some notifier
>   to userland.
> - never allocate any memory at running. (maybe it can't use libc.)
> - never be blocked by any locks, for example, some other task's mmap_sem.
>   One of typical mistakes of admins at OOM is typing 'ps' to see what
> happens.....
> - Can be used even with GUI system, which can't show console.

Hi Kame,

I am worried about run-time cost. 
Should we care of mistake of users for robustness of OS?
Mostly right but we can't handle all mistakes of user so we need admin.
For exampe, what happens if admin execute "rm -rf /"?
For avoiding it, we get a solution "backup" about critical data.

In the same manner, if the system is very critical of forkbomb, 
admin should consider it using memcg, virtualization, ulimit and so on.
If he don't want it, he should become a hard worker who have to 
cross over other building to reboot it. Although he is a diligent man, 
Reboot isn't good. So I suggest following patch which is just RFC. 
For making formal patch, I have to add more comment and modify sysrq.txt.