From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.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>
Subject: [PATCH 1/5] forkbomb killer config and documentation
Date: Thu, 24 Mar 2011 18:25:58 +0900 [thread overview]
Message-ID: <20110324182558.f5f811ab.kamezawa.hiroyu@jp.fujitsu.com> (raw)
In-Reply-To: <20110324182240.5fe56de2.kamezawa.hiroyu@jp.fujitsu.com>
Kconfig and Documentation for forkbomb killer.
Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
---
Documentation/vm/forkbomb.txt | 62 ++++++++++++++++++++++++++++++++++++++++++
mm/Kconfig | 16 ++++++++++
2 files changed, 78 insertions(+)
Index: mm-work2/Documentation/vm/forkbomb.txt
===================================================================
--- /dev/null
+++ mm-work2/Documentation/vm/forkbomb.txt
@@ -0,0 +1,62 @@
+Forkbomb.txt
+
+1. Intruduction
+ Maybe many programmer have an experience to write a fork-bomb program.
+
+ One example of fork-bomb is a bomb which make system unstable by the
+ memory pressure caused by the number of tasks. This kind of fork-bomb
+ can be limited by ulimit(max user processes). If it happens, the user
+ who has the same owner ID of forkbomb will not be able to do anything
+ but other users(admin) may have a chance to kill them. (Of course,
+ if forkbomb is created by root, we have no chance to recover.)
+
+ Another example of fork-bomb is a bomb which eats much memory. This
+ kind of forkbomb causes huge swapout and make system slow and finally,
+ OOM. In swapless system, the system will see OOM soon. To prevent this
+ type of bomb, memory cgroup or overcommit_memory will be a help. But
+ troubles happen when we don't expected.....
+
+ To recover from fork-bomb, we need to kill all tasks which is in the
+ forkbomb tree, in general. But if the system is in OOM state, killing
+ them all tends to be difficult.
+
+2. Forkbomb Killer.
+ The kernel provides a forkbomb killer. (see mm/Kconfig FORKBOMB_KILLER)
+ If enabled, the forkbomb killer will provides 2 system files.
+
+ /sys/kernel/mm/oom/mm_tracking_enabled
+ /sys/kernel/mm/oom/mm_tracking_reset_interval_msecs
+
+
+ If /sys/kernel/mm/oom/mm_tracking_enabled == enabled, the kernel records
+ all fork/vfork/exec information by an extra structure than usual task
+ management. This information is used for tracking a task tree. Unlike
+ process tree, this doesn't discard parent<->children information even
+ when the parent exits before children and make children as orphan processes.
+ By this, even with following script, task tracking information can be
+ preserved and we have a chance to chase all proceesses in a fork bomb.
+
+ (example) # forkbomb(){ forkbomb|forkbomb & } ; forkbomb
+
+ But this information tracking adds a small overhead at fork/vfork/exec/exit.
+ Default is enabled.
+
+ /sys/kernel/mm/oom/mm_tracking_reset_interval_msecs
+
+ Because we cannot preserve all information since the system boot, we need
+ to forget information. Forkbomb killer checks the system status in each
+ period. What checked now is
+ 1. the number of process.
+ 2. the number of kswapd runs.
+ 3. the number of alloc stalls. (memory reclaim)
+ If all of 1,2,3 aren't increased for mm_tracking_reset_interval_msecs,
+ all tracking information recorded before previous period will be
+ removed.
+ IOW, by making mm_tracking_reset_interval_msecs larger, you can check
+ forkbomb in a long period but will have more overheads. By making it
+ smaller, tracking records are removed earlier and tasks killed by
+ forkbomb killer will decrease (and you can avoid unnecessary kills.)
+ Default is 30secs.
+
+
+
Index: mm-work2/mm/Kconfig
===================================================================
--- mm-work2.orig/mm/Kconfig
+++ mm-work2/mm/Kconfig
@@ -274,6 +274,22 @@ config HWPOISON_INJECT
depends on MEMORY_FAILURE && DEBUG_KERNEL && PROC_FS
select PROC_PAGE_MONITOR
+config FORKBOMB_KILLER
+ bool "Killing a tree of tasks when a forkbomb is found"
+ depends on EXPERIMENTAL
+ default n
+ select MM_OWNER
+ help
+ Provide a fork-bomb-killer, which is triggered at OOM.
+ In usual case, OOM-Killer kills a memory eater processes.
+ But it kills tasks in conservative way and cannot be a help
+ if forkbomb is running. The admin may need to reboot system
+ if the influence of the bomb cannot be limited by rlimits or
+ some security settings. FORKBOMB Killer kills a tree of process
+ which have started recently and eats much memory. Please see,
+ Documentation/vm/forkbomb.txt for details. If unsure, say N.
+
+
config NOMMU_INITIAL_TRIM_EXCESS
int "Turn on mmap() excess space trimming before booting"
depends on !MMU
--
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>
next prev parent reply other threads:[~2011-03-24 9:32 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 ` KAMEZAWA Hiroyuki [this message]
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 ` [PATCH 0/4] " Minchan Kim
2011-03-25 0:04 ` 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=20110324182558.f5f811ab.kamezawa.hiroyu@jp.fujitsu.com \
--to=kamezawa.hiroyu@jp.fujitsu.com \
--cc=avagin@openvz.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--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