Return-Path: <linux-kernel-owner+w=401wt.eu-S1757564AbXKPSmF@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1757564AbXKPSmF (ORCPT <rfc822;w@1wt.eu>);
	Fri, 16 Nov 2007 13:42:05 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752411AbXKPSlT
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Fri, 16 Nov 2007 13:41:19 -0500
Received: from pentafluge.infradead.org ([213.146.154.40]:52849 "EHLO
	pentafluge.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1757789AbXKPSlQ (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 16 Nov 2007 13:41:16 -0500
Date: Fri, 16 Nov 2007 10:39:55 -0800
From: Greg Kroah-Hartman <gregkh@suse.de>
To: linux-kernel@vger.kernel.org, Andrew Morton <akpm@linux-foundation.org>,
       torvalds@linux-foundation.org, stable@kernel.org
Subject: Re: Linux 2.6.23.2
Message-ID: <20071116183955.GD9807@kroah.com>
References: <20071116183752.GA9807@kroah.com> <20071116183940.GC9807@kroah.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=unknown-8bit
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20071116183940.GC9807@kroah.com>
User-Agent: Mutt/1.5.16 (2007-06-09)
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 45913
Lines: 709

diff --git a/Documentation/ja_JP/HOWTO b/Documentation/ja_JP/HOWTO
index 9f08dab..d9d832c 100644
--- a/Documentation/ja_JP/HOWTO
+++ b/Documentation/ja_JP/HOWTO
@@ -1,4 +1,4 @@
-NOTE:
+NOTE:
 This is a version of Documentation/HOWTO translated into Japanese.
 This document is maintained by Tsugikazu Shibata <tshibata@ab.jp.nec.com>
 and the JF Project team <www.linux.or.jp/JF>.
@@ -11,14 +11,14 @@ for non English (read: Japanese) speakers and is not intended as a
 fork. So if you have any comments or updates for this file, please try
 to update the original English file first.
 
-Last Updated: 2007/07/18
+Last Updated: 2007/09/23
 ==================================
 これは、
-linux-2.6.22/Documentation/HOWTO
+linux-2.6.23/Documentation/HOWTO
 の和訳です。
 
 翻訳団体： JF プロジェクト < http://www.linux.or.jp/JF/ >
-翻訳日： 2007/07/16
+翻訳日： 2007/09/19
 翻訳者： Tsugikazu Shibata <tshibata at ab dot jp dot nec dot com>
 校正者： 松倉さん <nbh--mats at nifty dot com>
          小林 雅典さん (Masanori Kobayasi) <zap03216 at nifty dot ne dot jp>
@@ -27,6 +27,7 @@ linux-2.6.22/Documentation/HOWTO
          野口さん (Kenji Noguchi) <tokyo246 at gmail dot com>
          河内さん (Takayoshi Kochi) <t-kochi at bq dot jp dot nec dot com>
          岩本さん (iwamoto) <iwamoto.kn at ncos dot nec dot co dot jp>
+         内田さん (Satoshi Uchida) <s-uchida at ap dot jp dot nec dot com>
 ==================================
 
 Linux カーネル開発のやり方
@@ -40,7 +41,7 @@ Linux カーネル開発コミュニティと共に活動するやり方を学ã
 手助けになります。
 
 もし、このドキュメントのどこかが古くなっていた場合には、このドキュメン
-トの最後にリストしたメンテナーにパッチを送ってください。
+トの最後にリストしたメンテナにパッチを送ってください。
 
 はじめに
 ---------
@@ -59,7 +60,7 @@ Linux カーネル開発コミュニティと共に活動するやり方を学ã
 ネル開発者には必要です。アーキテクチャ向けの低レベル部分の開発をするの
 でなければ、(どんなアーキテクチャでも)アセンブリ(訳注: 言語)は必要あり
 ません。以下の本は、C 言語の十分な知識や何年もの経験に取って代わるもの
-ではありませんが、少なくともリファレンスとしてはいい本です。
+ではありませんが、少なくともリファレンスとしては良い本です。
  - "The C Programming Language" by Kernighan and Ritchie [Prentice Hall]
  -『プログラミング言語Ｃ第2版』(B.W. カーニハン/D.M. リッチー著 石田晴久訳) [共立出版]
  - "Practical C Programming" by Steve Oualline [O'Reilly]
@@ -76,7 +77,7 @@ Linux カーネル開発コミュニティと共に活動するやり方を学ã
 ときどき、カーネルがツールチェインや C 言語拡張に置いている前提がどう
 なっているのかわかりにくいことがあり、また、残念なことに決定的なリファ
 レンスは存在しません。情報を得るには、gcc の info ページ( info gcc )を
-みてください。
+見てください。
 
 あなたは既存の開発コミュニティと一緒に作業する方法を学ぼうとしているこ
 とに留意してください。そのコミュニティは、コーディング、スタイル、
@@ -92,7 +93,7 @@ Linux カーネル開発コミュニティと共に活動するやり方を学ã
 
 Linux カーネルのソースコードは GPL ライセンスの下でリリースされていま
 す。ライセンスの詳細については、ソースツリーのメインディレクトリに存在
-する、COPYING のファイルをみてください。もしライセンスについてさらに質
+する、COPYING のファイルを見てください。もしライセンスについてさらに質
 問があれば、Linux Kernel メーリングリストに質問するのではなく、どうぞ
 法律家に相談してください。メーリングリストの人達は法律家ではなく、法的
 問題については彼らの声明はあてにするべきではありません。
@@ -109,7 +110,8 @@ Linux カーネルソースツリーは幅広い範囲のドキュメントをå
 新しいドキュメントファイルも追加することを勧めます。
 カーネルの変更が、カーネルがユーザ空間に公開しているインターフェイスの
 変更を引き起こす場合、その変更を説明するマニュアルページのパッチや情報
-をマニュアルページのメンテナ mtk-manpages@gmx.net に送ることを勧めます。
+をマニュアルページのメンテナ mtk-manpages@gmx.net に送ることを勧めま
+す。
 
 以下はカーネルソースツリーに含まれている読んでおくべきファイルの一覧で
 す-
@@ -117,7 +119,7 @@ Linux カーネルソースツリーは幅広い範囲のドキュメントをå
   README
     このファイルは Linuxカーネルの簡単な背景とカーネルを設定(訳注
     configure )し、生成(訳注 build )するために必要なことは何かが書かれ
-    ています。カーネルに関して初めての人はここからスタートするとよいで
+    ています。カーネルに関して初めての人はここからスタートすると良いで
     しょう。
 
   Documentation/Changes
@@ -128,7 +130,7 @@ Linux カーネルソースツリーは幅広い範囲のドキュメントをå
   Documentation/CodingStyle
     これは Linux カーネルのコーディングスタイルと背景にある理由を記述
     しています。全ての新しいコードはこのドキュメントにあるガイドライン
-    に従っていることを期待されています。大部分のメンテナーはこれらのルー
+    に従っていることを期待されています。大部分のメンテナはこれらのルー
     ルに従っているものだけを受け付け、多くの人は正しいスタイルのコード
     だけをレビューします。
 
@@ -168,16 +170,16 @@ Linux カーネルソースツリーは幅広い範囲のドキュメントをå
     支援してください。
 
   Documentation/ManagementStyle
-    このドキュメントは Linux カーネルのメンテナー達がどう行動するか、
+    このドキュメントは Linux カーネルのメンテナ達がどう行動するか、
     彼らの手法の背景にある共有されている精神について記述しています。こ
     れはカーネル開発の初心者なら（もしくは、単に興味があるだけの人でも）
-    重要です。なぜならこのドキュメントは、カーネルメンテナー達の独特な
+    重要です。なぜならこのドキュメントは、カーネルメンテナ達の独特な
     行動についての多くの誤解や混乱を解消するからです。
 
   Documentation/stable_kernel_rules.txt
     このファイルはどのように stable カーネルのリリースが行われるかのルー
     ルが記述されています。そしてこれらのリリースの中のどこかで変更を取
-    り入れてもらいたい場合に何をすればいいかが示されています。
+    り入れてもらいたい場合に何をすれば良いかが示されています。
 
   Documentation/kernel-docs.txt
 　　カーネル開発に付随する外部ドキュメントのリストです。もしあなたが
@@ -218,9 +220,9 @@ web サイトには、コードの構成、サブシステム、現在存在すã
 ここには、また、カーネルのコンパイルのやり方やパッチの当て方などの間接
 的な基本情報も記述されています。
 
-あなたがどこからスタートしてよいかわからないが、Linux カーネル開発コミュ
+あなたがどこからスタートして良いかわからないが、Linux カーネル開発コミュ
 ニティに参加して何かすることをさがしている場合には、Linux kernel
-Janitor's プロジェクトにいけばよいでしょう -
+Janitor's プロジェクトにいけば良いでしょう -
 	http://janitor.kernelnewbies.org/
 ここはそのようなスタートをするのにうってつけの場所です。ここには、
 Linux カーネルソースツリーの中に含まれる、きれいにし、修正しなければな
@@ -243,7 +245,7 @@ Linux カーネルソースツリーの中に含まれる、きれいにし、ä¿
 自己参照方式で、索引がついた web 形式で、ソースコードを参照することが
 できます。この最新の素晴しいカーネルコードのリポジトリは以下で見つかり
 ます-
-	http://sosdg.org/~coywolf/lxr/
+	http://sosdg.org/~qiyong/lxr/
 
 開発プロセス
 -----------------------
@@ -265,9 +267,9 @@ Linux カーネルの開発プロセスは現在幾つかの異なるメインã‚
 以下のとおり-
 
   - 新しいカーネルがリリースされた直後に、2週間の特別期間が設けられ、
-    この期間中に、メンテナー達は Linus に大きな差分を送ることができま
-    す。このような差分は通常 -mm カーネルに数週間含まれてきたパッチで
-    す。 大きな変更は git(カーネルのソース管理ツール、詳細は
+    この期間中に、メンテナ達は Linus に大きな差分を送ることができます。
+    このような差分は通常 -mm カーネルに数週間含まれてきたパッチです。
+    大きな変更は git(カーネルのソース管理ツール、詳細は
     http://git.or.cz/  参照) を使って送るのが好ましいやり方ですが、パッ
     チファイルの形式のまま送るのでも十分です。
 
@@ -285,6 +287,10 @@ Linux カーネルの開発プロセスは現在幾つかの異なるメインã‚
     に安定した状態にあると判断したときにリリースされます。目標は毎週新
     しい -rc カーネルをリリースすることです。
 
+   - 以下の URL で各 -rc リリースに存在する既知の後戻り問題のリスト
+     が追跡されます-
+     http://kernelnewbies.org/known_regressions
+
   - このプロセスはカーネルが 「準備ができた」と考えられるまで継続しま
     す。このプロセスはだいたい 6週間継続します。
 
@@ -331,8 +337,8 @@ Andrew は個別のサブシステムカーネルツリーとパッチを全てé
 linux-kernel メーリングリストで収集された多数のパッチと同時に一つにま
 とめます。
 このツリーは新機能とパッチが検証される場となります。ある期間の間パッチ
-が -mm に入って価値を証明されたら、Andrew やサブシステムメンテナが、メ
-インラインへ入れるように Linus にプッシュします。
+が -mm に入って価値を証明されたら、Andrew やサブシステムメンテナが、
+メインラインへ入れるように Linus にプッシュします。
 
 メインカーネルツリーに含めるために Linus に送る前に、すべての新しいパッ
 チが -mm ツリーでテストされることが強く推奨されます。
@@ -460,7 +466,7 @@ MAINTAINERS ファイルにリストがありますので参照してくださã
 せん-
 彼らはあなたのパッチの行毎にコメントを入れたいので、そのためにはそうす
 るしかありません。あなたのメールプログラムが空白やタブを圧縮しないよう
-に確認した方がいいです。最初の良いテストとしては、自分にメールを送って
+に確認した方が良いです。最初の良いテストとしては、自分にメールを送って
 みて、そのパッチを自分で当ててみることです。もしそれがうまく行かないな
 ら、あなたのメールプログラムを直してもらうか、正しく動くように変えるべ
 きです。
@@ -507,14 +513,14 @@ MAINTAINERS ファイルにリストがありますので参照してくださã
 とも普通のことです。これはあなたのパッチが受け入れられないということで
 は *ありません*、そしてあなた自身に反対することを意味するのでも *ありま
 せん*。単に自分のパッチに対して指摘された問題を全て修正して再送すれば
-いいのです。
+良いのです。
 
 
 カーネルコミュニティと企業組織のちがい
 -----------------------------------------------------------------
 
 カーネルコミュニティは大部分の伝統的な会社の開発環境とは異ったやり方で
-動いています。以下は問題を避けるためにできるとよいことののリストです-
+動いています。以下は問題を避けるためにできると良いことのリストです-
 
   あなたの提案する変更について言うときのうまい言い方：
 
@@ -525,7 +531,7 @@ MAINTAINERS ファイルにリストがありますので参照してくださã
     - "以下は一連の小さなパッチ群ですが..."
     - "これは典型的なマシンでの性能を向上させます.."
 
-  やめた方がいい悪い言い方：
+  やめた方が良い悪い言い方：
 
     - このやり方で AIX/ptx/Solaris ではできたので、できるはずだ
     - 私はこれを20年もの間やってきた、だから
@@ -575,10 +581,10 @@ Linux カーネルコミュニティは、一度に大量のコードの塊をå–
 
 1) 小さいパッチはあなたのパッチが適用される見込みを大きくします、カー
    ネルの人達はパッチが正しいかどうかを確認する時間や労力をかけないか
-   らです。5行のパッチはメンテナがたった1秒見るだけで適用できます。し
-   かし、500行のパッチは、正しいことをレビューするのに数時間かかるかも
-   しれません(時間はパッチのサイズなどにより指数関数に比例してかかりま
-   す)
+   らです。5行のパッチはメンテナがたった1秒見るだけで適用できます。
+   しかし、500行のパッチは、正しいことをレビューするのに数時間かかるか
+   もしれません(時間はパッチのサイズなどにより指数関数に比例してかかり
+   ます)
 
    小さいパッチは何かあったときにデバッグもとても簡単になります。パッ
    チを1個1個取り除くのは、とても大きなパッチを当てた後に(かつ、何かお
@@ -587,23 +593,23 @@ Linux カーネルコミュニティは、一度に大量のコードの塊をå–
 2) 小さいパッチを送るだけでなく、送るまえに、書き直して、シンプルにす
    る(もしくは、単に順番を変えるだけでも)ことも、とても重要です。
 
-以下はカーネル開発者の Al Viro のたとえ話しです：
+以下はカーネル開発者の Al Viro のたとえ話です：
 
         "生徒の数学の宿題を採点する先生のことを考えてみてください、先
-        生は生徒が解に到達するまでの試行錯誤をみたいとは思わないでしょ
-        う。先生は簡潔な最高の解をみたいのです。良い生徒はこれを知って
+        生は生徒が解に到達するまでの試行錯誤を見たいとは思わないでしょ
+        う。先生は簡潔な最高の解を見たいのです。良い生徒はこれを知って
         おり、そして最終解の前の中間作業を提出することは決してないので
         す"
 
-        カーネル開発でもこれは同じです。メンテナー達とレビューア達は、
-        問題を解決する解の背後になる思考プロセスをみたいとは思いません。
-        彼らは単純であざやかな解決方法をみたいのです。
+        カーネル開発でもこれは同じです。メンテナ達とレビューア達は、
+        問題を解決する解の背後になる思考プロセスを見たいとは思いません。
+        彼らは単純であざやかな解決方法を見たいのです。
 
 あざやかな解を説明するのと、コミュニティと共に仕事をし、未解決の仕事を
 議論することのバランスをキープするのは難しいかもしれません。
 ですから、開発プロセスの早期段階で改善のためのフィードバックをもらうよ
-うにするのもいいですが、変更点を小さい部分に分割して全体ではまだ完成し
-ていない仕事を(部分的に)取り込んでもらえるようにすることもいいことです。
+うにするのも良いですが、変更点を小さい部分に分割して全体ではまだ完成し
+ていない仕事を(部分的に)取り込んでもらえるようにすることも良いことです。
 
 また、でき上がっていないものや、"将来直す" ようなパッチを、本流に含め
 てもらうように送っても、それは受け付けられないことを理解してください。
@@ -629,7 +635,7 @@ Linux カーネルコミュニティは、一度に大量のコードの塊をå–
   - テスト結果
 
 これについて全てがどのようにあるべきかについての詳細は、以下のドキュメ
-ントの ChangeLog セクションをみてください-
+ントの ChangeLog セクションを見てください-
   "The Perfect Patch"
       http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
 
diff --git a/Makefile b/Makefile
index c244a02..c6d545c 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
 VERSION = 2
 PATCHLEVEL = 6
 SUBLEVEL = 23
-EXTRAVERSION = .1
+EXTRAVERSION = .2
 NAME = Arr Matey! A Hairy Bilge Rat!
 
 # *DOCUMENTATION*
diff --git a/block/ll_rw_blk.c b/block/ll_rw_blk.c
index ed39313..026cf24 100644
--- a/block/ll_rw_blk.c
+++ b/block/ll_rw_blk.c
@@ -819,7 +819,6 @@ static int __blk_free_tags(struct blk_queue_tag *bqt)
 	retval = atomic_dec_and_test(&bqt->refcnt);
 	if (retval) {
 		BUG_ON(bqt->busy);
-		BUG_ON(!list_empty(&bqt->busy_list));
 
 		kfree(bqt->tag_index);
 		bqt->tag_index = NULL;
@@ -931,7 +930,6 @@ static struct blk_queue_tag *__blk_queue_init_tags(struct request_queue *q,
 	if (init_tag_map(q, tags, depth))
 		goto fail;
 
-	INIT_LIST_HEAD(&tags->busy_list);
 	tags->busy = 0;
 	atomic_set(&tags->refcnt, 1);
 	return tags;
@@ -982,6 +980,7 @@ int blk_queue_init_tags(struct request_queue *q, int depth,
 	 */
 	q->queue_tags = tags;
 	q->queue_flags |= (1 << QUEUE_FLAG_QUEUED);
+	INIT_LIST_HEAD(&q->tag_busy_list);
 	return 0;
 fail:
 	kfree(tags);
@@ -1152,7 +1151,7 @@ int blk_queue_start_tag(struct request_queue *q, struct request *rq)
 	rq->tag = tag;
 	bqt->tag_index[tag] = rq;
 	blkdev_dequeue_request(rq);
-	list_add(&rq->queuelist, &bqt->busy_list);
+	list_add(&rq->queuelist, &q->tag_busy_list);
 	bqt->busy++;
 	return 0;
 }
@@ -1173,11 +1172,10 @@ EXPORT_SYMBOL(blk_queue_start_tag);
  **/
 void blk_queue_invalidate_tags(struct request_queue *q)
 {
-	struct blk_queue_tag *bqt = q->queue_tags;
 	struct list_head *tmp, *n;
 	struct request *rq;
 
-	list_for_each_safe(tmp, n, &bqt->busy_list) {
+	list_for_each_safe(tmp, n, &q->tag_busy_list) {
 		rq = list_entry_rq(tmp);
 
 		if (rq->tag == -1) {
diff --git a/fs/locks.c b/fs/locks.c
index c795eaa..494f250 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -694,11 +694,20 @@ EXPORT_SYMBOL(posix_test_lock);
  * Note: the above assumption may not be true when handling lock requests
  * from a broken NFS client. But broken NFS clients have a lot more to
  * worry about than proper deadlock detection anyway... --okir
+ *
+ * However, the failure of this assumption (also possible in the case of
+ * multiple tasks sharing the same open file table) also means there's no
+ * guarantee that the loop below will terminate.  As a hack, we give up
+ * after a few iterations.
  */
+
+#define MAX_DEADLK_ITERATIONS 10
+
 static int posix_locks_deadlock(struct file_lock *caller_fl,
 				struct file_lock *block_fl)
 {
 	struct list_head *tmp;
+	int i = 0;
 
 next_task:
 	if (posix_same_owner(caller_fl, block_fl))
@@ -706,6 +715,8 @@ next_task:
 	list_for_each(tmp, &blocked_list) {
 		struct file_lock *fl = list_entry(tmp, struct file_lock, fl_link);
 		if (posix_same_owner(fl, block_fl)) {
+			if (i++ > MAX_DEADLK_ITERATIONS)
+				return 0;
 			fl = fl->fl_next;
 			block_fl = fl;
 			goto next_task;
diff --git a/fs/proc/array.c b/fs/proc/array.c
index ee4814d..20d7ae4 100644
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -351,7 +351,8 @@ static cputime_t task_utime(struct task_struct *p)
 	}
 	utime = (clock_t)temp;
 
-	return clock_t_to_cputime(utime);
+	p->prev_utime = max(p->prev_utime, clock_t_to_cputime(utime));
+	return p->prev_utime;
 }
 
 static cputime_t task_stime(struct task_struct *p)
@@ -366,7 +367,8 @@ static cputime_t task_stime(struct task_struct *p)
 	stime = nsec_to_clock_t(p->se.sum_exec_runtime) -
 			cputime_to_clock_t(task_utime(p));
 
-	return clock_t_to_cputime(stime);
+	p->prev_stime = max(p->prev_stime, clock_t_to_cputime(stime));
+	return p->prev_stime;
 }
 #endif
 
diff --git a/fs/splice.c b/fs/splice.c
index e95a362..02c39ae 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -1390,10 +1390,10 @@ static int pipe_to_user(struct pipe_inode_info *pipe, struct pipe_buffer *buf,
 	if (copy_to_user(sd->u.userptr, src + buf->offset, sd->len))
 		ret = -EFAULT;
 
+	buf->ops->unmap(pipe, buf, src);
 out:
 	if (ret > 0)
 		sd->u.userptr += ret;
-	buf->ops->unmap(pipe, buf, src);
 	return ret;
 }
 
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index b126c6f..d26bbb0 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -356,7 +356,6 @@ enum blk_queue_state {
 struct blk_queue_tag {
 	struct request **tag_index;	/* map of busy tags */
 	unsigned long *tag_map;		/* bit map of free/busy tags */
-	struct list_head busy_list;	/* fifo list of busy tags */
 	int busy;			/* current depth */
 	int max_depth;			/* what we will send to device */
 	int real_max_depth;		/* what the array can hold */
@@ -451,6 +450,7 @@ struct request_queue
 	unsigned int		dma_alignment;
 
 	struct blk_queue_tag	*queue_tags;
+	struct list_head	tag_busy_list;
 
 	unsigned int		nr_sorted;
 	unsigned int		in_flight;
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 313c6b6..f509fbd 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1022,6 +1022,7 @@ struct task_struct {
 
 	unsigned int rt_priority;
 	cputime_t utime, stime;
+	cputime_t prev_utime, prev_stime;
 	unsigned long nvcsw, nivcsw; /* context switch counts */
 	struct timespec start_time; 		/* monotonic time */
 	struct timespec real_start_time;	/* boot based time */
diff --git a/kernel/fork.c b/kernel/fork.c
index 33f12f4..f299d45 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1045,6 +1045,8 @@ static struct task_struct *copy_process(unsigned long clone_flags,
 
 	p->utime = cputime_zero;
 	p->stime = cputime_zero;
+	p->prev_utime = cputime_zero;
+	p->prev_stime = cputime_zero;
 
 #ifdef CONFIG_TASK_XACCT
 	p->rchar = 0;		/* I/O counter: bytes read */
diff --git a/kernel/futex_compat.c b/kernel/futex_compat.c
index 2c2e295..f938c23 100644
--- a/kernel/futex_compat.c
+++ b/kernel/futex_compat.c
@@ -29,6 +29,15 @@ fetch_robust_entry(compat_uptr_t *uentry, struct robust_list __user **entry,
 	return 0;
 }
 
+static void __user *futex_uaddr(struct robust_list *entry,
+				compat_long_t futex_offset)
+{
+	compat_uptr_t base = ptr_to_compat(entry);
+	void __user *uaddr = compat_ptr(base + futex_offset);
+
+	return uaddr;
+}
+
 /*
  * Walk curr->robust_list (very carefully, it's a userspace list!)
  * and mark any locks found there dead, and notify any waiters.
@@ -75,11 +84,13 @@ void compat_exit_robust_list(struct task_struct *curr)
 		 * A pending lock might already be on the list, so
 		 * dont process it twice:
 		 */
-		if (entry != pending)
-			if (handle_futex_death((void __user *)entry + futex_offset,
-						curr, pi))
-				return;
+		if (entry != pending) {
+			void __user *uaddr = futex_uaddr(entry,
+							 futex_offset);
 
+			if (handle_futex_death(uaddr, curr, pi))
+				return;
+		}
 		if (rc)
 			return;
 		uentry = next_uentry;
@@ -93,9 +104,11 @@ void compat_exit_robust_list(struct task_struct *curr)
 
 		cond_resched();
 	}
-	if (pending)
-		handle_futex_death((void __user *)pending + futex_offset,
-				   curr, pip);
+	if (pending) {
+		void __user *uaddr = futex_uaddr(pending, futex_offset);
+
+		handle_futex_death(uaddr, curr, pip);
+	}
 }
 
 asmlinkage long
diff --git a/kernel/lockdep.c b/kernel/lockdep.c
index 734da57..42ae4a5 100644
--- a/kernel/lockdep.c
+++ b/kernel/lockdep.c
@@ -1521,7 +1521,7 @@ cache_hit:
 }
 
 static int validate_chain(struct task_struct *curr, struct lockdep_map *lock,
-	       	struct held_lock *hlock, int chain_head)
+	       	struct held_lock *hlock, int chain_head, u64 chain_key)
 {
 	/*
 	 * Trylock needs to maintain the stack of held locks, but it
@@ -1534,7 +1534,7 @@ static int validate_chain(struct task_struct *curr, struct lockdep_map *lock,
 	 * graph_lock for us)
 	 */
 	if (!hlock->trylock && (hlock->check == 2) &&
-			lookup_chain_cache(curr->curr_chain_key, hlock->class)) {
+			lookup_chain_cache(chain_key, hlock->class)) {
 		/*
 		 * Check whether last held lock:
 		 *
@@ -1576,7 +1576,7 @@ static int validate_chain(struct task_struct *curr, struct lockdep_map *lock,
 #else
 static inline int validate_chain(struct task_struct *curr,
 	       	struct lockdep_map *lock, struct held_lock *hlock,
-		int chain_head)
+		int chain_head, u64 chain_key)
 {
 	return 1;
 }
@@ -2450,11 +2450,11 @@ static int __lock_acquire(struct lockdep_map *lock, unsigned int subclass,
 		chain_head = 1;
 	}
 	chain_key = iterate_chain_key(chain_key, id);
-	curr->curr_chain_key = chain_key;
 
-	if (!validate_chain(curr, lock, hlock, chain_head))
+	if (!validate_chain(curr, lock, hlock, chain_head, chain_key))
 		return 0;
 
+	curr->curr_chain_key = chain_key;
 	curr->lockdep_depth++;
 	check_chain_key(curr);
 #ifdef CONFIG_DEBUG_LOCKDEP
diff --git a/kernel/params.c b/kernel/params.c
index 4e57732..5e5651f 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -595,13 +595,16 @@ static void __init param_sysfs_builtin(void)
 
 	for (i=0; i < __stop___param - __start___param; i++) {
 		char *dot;
+		size_t max_name_len;
 
 		kp = &__start___param[i];
+		max_name_len =
+			min_t(size_t, MAX_KBUILD_MODNAME, strlen(kp->name));
 
-		/* We do not handle args without periods. */
-		dot = memchr(kp->name, '.', MAX_KBUILD_MODNAME);
+		dot = memchr(kp->name, '.', max_name_len);
 		if (!dot) {
-			DEBUGP("couldn't find period in %s\n", kp->name);
+			DEBUGP("couldn't find period in first %d characters "
+			       "of %s\n", MAX_KBUILD_MODNAME, kp->name);
 			continue;
 		}
 		name_len = dot - kp->name;
diff --git a/kernel/softlockup.c b/kernel/softlockup.c
index 708d488..e557c44 100644
--- a/kernel/softlockup.c
+++ b/kernel/softlockup.c
@@ -80,10 +80,11 @@ void softlockup_tick(void)
 	print_timestamp = per_cpu(print_timestamp, this_cpu);
 
 	/* report at most once a second */
-	if (print_timestamp < (touch_timestamp + 1) ||
-		did_panic ||
-			!per_cpu(watchdog_task, this_cpu))
+	if ((print_timestamp >= touch_timestamp &&
+			print_timestamp < (touch_timestamp + 1)) ||
+			did_panic || !per_cpu(watchdog_task, this_cpu)) {
 		return;
+	}
 
 	/* do not print during early bootup: */
 	if (unlikely(system_state != SYSTEM_RUNNING)) {
diff --git a/mm/filemap.c b/mm/filemap.c
index 15c8413..14ca63f 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -1312,7 +1312,7 @@ int filemap_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 
 	size = (i_size_read(inode) + PAGE_CACHE_SIZE - 1) >> PAGE_CACHE_SHIFT;
 	if (vmf->pgoff >= size)
-		goto outside_data_content;
+		return VM_FAULT_SIGBUS;
 
 	/* If we don't want any read-ahead, don't bother */
 	if (VM_RandomReadHint(vma))
@@ -1389,7 +1389,7 @@ retry_find:
 	if (unlikely(vmf->pgoff >= size)) {
 		unlock_page(page);
 		page_cache_release(page);
-		goto outside_data_content;
+		return VM_FAULT_SIGBUS;
 	}
 
 	/*
@@ -1400,15 +1400,6 @@ retry_find:
 	vmf->page = page;
 	return ret | VM_FAULT_LOCKED;
 
-outside_data_content:
-	/*
-	 * An external ptracer can access pages that normally aren't
-	 * accessible..
-	 */
-	if (vma->vm_mm == current->mm)
-		return VM_FAULT_SIGBUS;
-
-	/* Fall through to the non-read-ahead case */
 no_cached_page:
 	/*
 	 * We're only likely to ever get here if MADV_RANDOM is in
diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index 4472036..97ddc58 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -672,8 +672,10 @@ retry:
 
 			ret = (*writepage)(page, wbc, data);
 
-			if (unlikely(ret == AOP_WRITEPAGE_ACTIVATE))
+			if (unlikely(ret == AOP_WRITEPAGE_ACTIVATE)) {
 				unlock_page(page);
+				ret = 0;
+			}
 			if (ret || (--(wbc->nr_to_write) <= 0))
 				done = 1;
 			if (wbc->nonblocking && bdi_write_congested(bdi)) {
diff --git a/mm/shmem.c b/mm/shmem.c
index fcd19d3..95558e4 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -916,6 +916,21 @@ static int shmem_writepage(struct page *page, struct writeback_control *wbc)
 	struct inode *inode;
 
 	BUG_ON(!PageLocked(page));
+	/*
+	 * shmem_backing_dev_info's capabilities prevent regular writeback or
+	 * sync from ever calling shmem_writepage; but a stacking filesystem
+	 * may use the ->writepage of its underlying filesystem, in which case
+	 * we want to do nothing when that underlying filesystem is tmpfs
+	 * (writing out to swap is useful as a response to memory pressure, but
+	 * of no use to stabilize the data) - just redirty the page, unlock it
+	 * and claim success in this case.  AOP_WRITEPAGE_ACTIVATE, and the
+	 * page_mapped check below, must be avoided unless we're in reclaim.
+	 */
+	if (!wbc->for_reclaim) {
+		set_page_dirty(page);
+		unlock_page(page);
+		return 0;
+	}
 	BUG_ON(page_mapped(page));
 
 	mapping = page->mapping;
diff --git a/mm/slub.c b/mm/slub.c
index addb20a..c1f2fda 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1501,28 +1501,8 @@ new_slab:
 	page = new_slab(s, gfpflags, node);
 	if (page) {
 		cpu = smp_processor_id();
-		if (s->cpu_slab[cpu]) {
-			/*
-			 * Someone else populated the cpu_slab while we
-			 * enabled interrupts, or we have gotten scheduled
-			 * on another cpu. The page may not be on the
-			 * requested node even if __GFP_THISNODE was
-			 * specified. So we need to recheck.
-			 */
-			if (node == -1 ||
-				page_to_nid(s->cpu_slab[cpu]) == node) {
-				/*
-				 * Current cpuslab is acceptable and we
-				 * want the current one since its cache hot
-				 */
-				discard_slab(s, page);
-				page = s->cpu_slab[cpu];
-				slab_lock(page);
-				goto load_freelist;
-			}
-			/* New slab does not fit our expectations */
+		if (s->cpu_slab[cpu])
 			flush_slab(s, s->cpu_slab[cpu], cpu);
-		}
 		slab_lock(page);
 		SetSlabFrozen(page);
 		s->cpu_slab[cpu] = page;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/