linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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>

  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