---

yaml --- r: 130447 b: refs/heads/master c: 720893f h: refs/heads/master i: 130445: 567db13 130443: 52cfb54 130439: 545f2df 130431: bc30172 v: v3
git-mirror · Jan 28, 2009 · fc70cd8 · fc70cd8
1 parent 9db032a
commit fc70cd8
Show file tree

Hide file tree

Showing 64 changed files with 468 additions and 853 deletions.
diff --git a/[refs] b/[refs]
@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 05986e264ee638b6b6151aea89c9f191278c30f1
+refs/heads/master: 720893fd5fb6de1f752f816a89e630f08ae8b20a
diff --git a/trunk/Documentation/cgroups/memcg_test.txt b/trunk/Documentation/cgroups/memcg_test.txt
@@ -1,6 +1,6 @@
 Memory Resource Controller(Memcg)  Implementation Memo.
-Last Updated: 2009/1/19
-Base Kernel Version: based on 2.6.29-rc2.
+Last Updated: 2008/12/15
+Base Kernel Version: based on 2.6.28-rc8-mm.
 
 Because VM is getting complex (one of reasons is memcg...), memcg's behavior
 is complex. This is a document for memcg's internal behavior.
@@ -340,23 +340,3 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
 	# mount -t cgroup none /cgroup -t cpuset,memory,cpu,devices
 
 	and do task move, mkdir, rmdir etc...under this.
-
- 9.7 swapoff.
-	Besides management of swap is one of complicated parts of memcg,
-	call path of swap-in at swapoff is not same as usual swap-in path..
-	It's worth to be tested explicitly.
-
-	For example, test like following is good.
-	(Shell-A)
-	# mount -t cgroup none /cgroup -t memory
-	# mkdir /cgroup/test
-	# echo 40M > /cgroup/test/memory.limit_in_bytes
-	# echo 0 > /cgroup/test/tasks
-	Run malloc(100M) program under this. You'll see 60M of swaps.
-	(Shell-B)
-	# move all tasks in /cgroup/test to /cgroup
-	# /sbin/swapoff -a
-	# rmdir /test/cgroup
-	# kill malloc task.
-
-	Of course, tmpfs v.s. swapoff test should be tested, too.
diff --git a/trunk/Documentation/filesystems/proc.txt b/trunk/Documentation/filesystems/proc.txt
@@ -2027,34 +2027,6 @@ increase the likelihood of this process being killed by the oom-killer.  Valid
 values are in the range -16 to +15, plus the special value -17, which disables
 oom-killing altogether for this process.
 
-The process to be killed in an out-of-memory situation is selected among all others
-based on its badness score. This value equals the original memory size of the process
-and is then updated according to its CPU time (utime + stime) and the
-run time (uptime - start time). The longer it runs the smaller is the score.
-Badness score is divided by the square root of the CPU time and then by
-the double square root of the run time.
-
-Swapped out tasks are killed first. Half of each child's memory size is added to
-the parent's score if they do not share the same memory. Thus forking servers
-are the prime candidates to be killed. Having only one 'hungry' child will make
-parent less preferable than the child.
-
-/proc/<pid>/oom_score shows process' current badness score.
-
-The following heuristics are then applied:
- * if the task was reniced, its score doubles
- * superuser or direct hardware access tasks (CAP_SYS_ADMIN, CAP_SYS_RESOURCE
- 	or CAP_SYS_RAWIO) have their score divided by 4
- * if oom condition happened in one cpuset and checked task does not belong
- 	to it, its score is divided by 8
- * the resulting score is multiplied by two to the power of oom_adj, i.e.
-	points <<= oom_adj when it is positive and
-	points >>= -(oom_adj) otherwise
-
-The task with the highest badness score is then selected and its children
-are killed, process itself will be killed in an OOM situation when it does
-not have children or some of them disabled oom like described above.
-
 2.13 /proc/<pid>/oom_score - Display current oom-killer score
 -------------------------------------------------------------
 

diff --git a/trunk/Documentation/ja_JP/stable_kernel_rules.txt b/trunk/Documentation/ja_JP/stable_kernel_rules.txt
@@ -12,11 +12,11 @@ file at first.
 
 ==================================
 これは、
-linux-2.6.24/Documentation/stable_kernel_rules.txt
+linux-2.6.29/Documentation/stable_kernel_rules.txt
 の和訳です。
 
 翻訳団体： JF プロジェクト < http://www.linux.or.jp/JF/ >
-翻訳日： 2007/12/30
+翻訳日： 2009/1/14
 翻訳者： Tsugikazu Shibata <tshibata at ab dot jp dot nec dot com>
 校正者： 武井伸光さん、<takei at webmasters dot gr dot jp>
          かねこさん (Seiji Kaneko) <skaneko at a2 dot mbn dot or dot jp>
@@ -38,12 +38,15 @@ linux-2.6.24/Documentation/stable_kernel_rules.txt
  - ビルドエラー(CONFIG_BROKENになっているものを除く), oops, ハング、デー
    タ破壊、現実のセキュリティ問題、その他 "ああ、これはダメだね"という
    ようなものを修正しなければならない。短く言えば、重大な問題。
+ - 新しい device ID とクオークも受け入れられる。
  - どのように競合状態が発生するかの説明も一緒に書かれていない限り、
    "理論的には競合状態になる"ようなものは不可。
  - いかなる些細な修正も含めることはできない。(スペルの修正、空白のクリー
    ンアップなど)
- - 対応するサブシステムメンテナが受け入れたものでなければならない。
  - Documentation/SubmittingPatches の規則に従ったものでなければならない。
+ - パッチ自体か同等の修正が Linus のツリーに既に存在しなければならない。
+　 Linus のツリーでのコミットID を -stable へのパッチ投稿の際に引用す
+   ること。
 
 -stable ツリーにパッチを送付する手続き-
 
@@ -52,8 +55,10 @@ linux-2.6.24/Documentation/stable_kernel_rules.txt
  - 送信者はパッチがキューに受け付けられた際には ACK を、却下された場合
    には NAK を受け取る。この反応は開発者たちのスケジュールによって、数
    日かかる場合がある。
- - もし受け取られたら、パッチは他の開発者たちのレビューのために
-   -stable キューに追加される。
+ - もし受け取られたら、パッチは他の開発者たちと関連するサブシステムの
+   メンテナーによるレビューのために -stable キューに追加される。
+ - パッチに stable@kernel.org のアドレスが付加されているときには、それ
+   が Linus のツリーに入る時に自動的に stable チームに email される。
  - セキュリティパッチはこのエイリアス (stable@kernel.org) に送られるべ
    きではなく、代わりに security@kernel.org のアドレスに送られる。
 

diff --git a/trunk/Documentation/lguest/Makefile b/trunk/Documentation/lguest/Makefile
@@ -1,5 +1,5 @@
 # This creates the demonstration utility "lguest" which runs a Linux guest.
-CFLAGS:=-Wall -Wmissing-declarations -Wmissing-prototypes -O3 -I../../include -I../../arch/x86/include -U_FORTIFY_SOURCE
+CFLAGS:=-Wall -Wmissing-declarations -Wmissing-prototypes -O3 -I../../include -I../../arch/x86/include
 LDLIBS:=-lz
 
 all: lguest

diff --git a/trunk/arch/alpha/Kconfig b/trunk/arch/alpha/Kconfig
@@ -8,7 +8,6 @@ config ALPHA
 	select HAVE_AOUT
 	select HAVE_IDE
 	select HAVE_OPROFILE
-	select HAVE_SYSCALL_WRAPPERS
 	help
 	  The Alpha is a 64-bit general-purpose processor designed and
 	  marketed by the Digital Equipment Corporation of blessed memory,

diff --git a/trunk/arch/alpha/include/asm/bug.h b/trunk/arch/alpha/include/asm/bug.h
@@ -8,12 +8,17 @@
 
 /* ??? Would be nice to use .gprel32 here, but we can't be sure that the
    function loaded the GP, so this could fail in modules.  */
-#define BUG()	{							\
-	__asm__ __volatile__(						\
-		"call_pal %0  # bugchk\n\t"				\
-		".long %1\n\t.8byte %2"					\
-		: : "i"(PAL_bugchk), "i"(__LINE__), "i"(__FILE__));	\
-	for ( ; ; ); }
+static inline void ATTRIB_NORET __BUG(const char *file, int line)
+{
+	__asm__ __volatile__(
+		"call_pal %0  # bugchk\n\t"
+		".long %1\n\t.8byte %2"
+		       : : "i" (PAL_bugchk), "i"(line), "i"(file));
+	for ( ; ; )
+		;
+}
+
+#define BUG() __BUG(__FILE__, __LINE__)
 
 #define HAVE_ARCH_BUG
 #endif

diff --git a/trunk/arch/alpha/include/asm/dma-mapping.h b/trunk/arch/alpha/include/asm/dma-mapping.h
@@ -29,8 +29,6 @@
 
 #else	/* no PCI - no IOMMU. */
 
-#include <asm/io.h>	/* for virt_to_phys() */
-
 struct scatterlist;
 void *dma_alloc_coherent(struct device *dev, size_t size,
 			 dma_addr_t *dma_handle, gfp_t gfp);

diff --git a/trunk/arch/alpha/kernel/entry.S b/trunk/arch/alpha/kernel/entry.S
@@ -933,7 +933,7 @@ sys_execve:
 osf_sigprocmask:
 	.prologue 0
 	mov	$sp, $18
-	jmp	$31, sys_osf_sigprocmask
+	jmp	$31, do_osf_sigprocmask
 .end osf_sigprocmask
 
 	.align	4