Magellan Linux

  • Back to homepage
    • /[pkg-src]/trunk/kernel26-alx/patches-2.6.23-r1/0101-2.6.23.2-all-fixes.patch

    Contents of /trunk/kernel26-alx/patches-2.6.23-r1/0101-2.6.23.2-all-fixes.patch

    Parent Directory Parent Directory | Revision Log Revision Log

    Revision 658 - (show annotations) (download)
    Mon Jun 23 21:39:39 2008 UTC (15 years, 10 months ago) by niro
    File size: 31184 byte(s) 
    2.6.23-alx-r1: new default as we fix the via epia clocksource=tsc quircks
-linux-2.6.23.17
-fbcondecor-0.9.4
-squashfs-3.3
-unionfs-2.3.3
-ipw3945-1.2.2
-mptbase-vmware fix
    1 diff --git a/Documentation/ja_JP/HOWTO b/Documentation/ja_JP/HOWTO
    2 index 9f08dab..d9d832c 100644
    3 --- a/Documentation/ja_JP/HOWTO
    4 +++ b/Documentation/ja_JP/HOWTO
    5 @@ -1,4 +1,4 @@
    6 -NOTE:
    7 +NOTE:
    8 This is a version of Documentation/HOWTO translated into Japanese.
    9 This document is maintained by Tsugikazu Shibata <tshibata@ab.jp.nec.com>
    10 and the JF Project team <www.linux.or.jp/JF>.
    11 @@ -11,14 +11,14 @@ for non English (read: Japanese) speakers and is not intended as a
    12 fork. So if you have any comments or updates for this file, please try
    13 to update the original English file first.
    14
    15 -Last Updated: 2007/07/18
    16 +Last Updated: 2007/09/23
    17 ==================================
    18 これは、
    19 -linux-2.6.22/Documentation/HOWTO
    20 +linux-2.6.23/Documentation/HOWTO
    21 の和訳です。
    22
    23 翻訳団体： JF プロジェクト < http://www.linux.or.jp/JF/ >
    24 -翻訳日： 2007/07/16
    25 +翻訳日： 2007/09/19
    26 翻訳者： Tsugikazu Shibata <tshibata at ab dot jp dot nec dot com>
    27 校正者： 松倉さん <nbh--mats at nifty dot com>
    28 小林 雅典さん (Masanori Kobayasi) <zap03216 at nifty dot ne dot jp>
    29 @@ -27,6 +27,7 @@ linux-2.6.22/Documentation/HOWTO
    30 野口さん (Kenji Noguchi) <tokyo246 at gmail dot com>
    31 河内さん (Takayoshi Kochi) <t-kochi at bq dot jp dot nec dot com>
    32 岩本さん (iwamoto) <iwamoto.kn at ncos dot nec dot co dot jp>
    33 + 内田さん (Satoshi Uchida) <s-uchida at ap dot jp dot nec dot com>
    34 ==================================
    35
    36 Linux カーネル開発のやり方
    37 @@ -40,7 +41,7 @@ Linux カーネル開発コミュニティと共に活動するやり方を学
    38 手助けになります。
    39
    40 もし、このドキュメントのどこかが古くなっていた場合には、このドキュメン
    41 -トの最後にリストしたメンテナーにパッチを送ってください。
    42 +トの最後にリストしたメンテナにパッチを送ってください。
    43
    44 はじめに
    45 ---------
    46 @@ -59,7 +60,7 @@ Linux カーネル開発コミュニティと共に活動するやり方を学
    47 ネル開発者には必要です。アーキテクチャ向けの低レベル部分の開発をするの
    48 でなければ、(どんなアーキテクチャでも)アセンブリ(訳注: 言語)は必要あり
    49 ません。以下の本は、C 言語の十分な知識や何年もの経験に取って代わるもの
    50 -ではありませんが、少なくともリファレンスとしてはいい本です。
    51 +ではありませんが、少なくともリファレンスとしては良い本です。
    52 - "The C Programming Language" by Kernighan and Ritchie [Prentice Hall]
    53 -『プログラミング言語Ｃ第2版』(B.W. カーニハン/D.M. リッチー著 石田晴久訳) [共立出版]
    54 - "Practical C Programming" by Steve Oualline [O'Reilly]
    55 @@ -76,7 +77,7 @@ Linux カーネル開発コミュニティと共に活動するやり方を学
    56 ときどき、カーネルがツールチェインや C 言語拡張に置いている前提がどう
    57 なっているのかわかりにくいことがあり、また、残念なことに決定的なリファ
    58 レンスは存在しません。情報を得るには、gcc の info ページ( info gcc )を
    59 -みてください。
    60 +見てください。
    61
    62 あなたは既存の開発コミュニティと一緒に作業する方法を学ぼうとしているこ
    63 とに留意してください。そのコミュニティは、コーディング、スタイル、
    64 @@ -92,7 +93,7 @@ Linux カーネル開発コミュニティと共に活動するやり方を学
    65
    66 Linux カーネルのソースコードは GPL ライセンスの下でリリースされていま
    67 す。ライセンスの詳細については、ソースツリーのメインディレクトリに存在
    68 -する、COPYING のファイルをみてください。もしライセンスについてさらに質
    69 +する、COPYING のファイルを見てください。もしライセンスについてさらに質
    70 問があれば、Linux Kernel メーリングリストに質問するのではなく、どうぞ
    71 法律家に相談してください。メーリングリストの人達は法律家ではなく、法的
    72 問題については彼らの声明はあてにするべきではありません。
    73 @@ -109,7 +110,8 @@ Linux カーネルソースツリーは幅広い範囲のドキュメントを
    74 新しいドキュメントファイルも追加することを勧めます。
    75 カーネルの変更が、カーネルがユーザ空間に公開しているインターフェイスの
    76 変更を引き起こす場合、その変更を説明するマニュアルページのパッチや情報
    77 -をマニュアルページのメンテナ mtk-manpages@gmx.net に送ることを勧めます。
    78 +をマニュアルページのメンテナ mtk-manpages@gmx.net に送ることを勧めま
    79 +す。
    80
    81 以下はカーネルソースツリーに含まれている読んでおくべきファイルの一覧で
    82 す-
    83 @@ -117,7 +119,7 @@ Linux カーネルソースツリーは幅広い範囲のドキュメントを
    84 README
    85 このファイルは Linuxカーネルの簡単な背景とカーネルを設定(訳注
    86 configure )し、生成(訳注 build )するために必要なことは何かが書かれ
    87 - ています。カーネルに関して初めての人はここからスタートするとよいで
    88 + ています。カーネルに関して初めての人はここからスタートすると良いで
    89 しょう。
    90
    91 Documentation/Changes
    92 @@ -128,7 +130,7 @@ Linux カーネルソースツリーは幅広い範囲のドキュメントを
    93 Documentation/CodingStyle
    94 これは Linux カーネルのコーディングスタイルと背景にある理由を記述
    95 しています。全ての新しいコードはこのドキュメントにあるガイドライン
    96 - に従っていることを期待されています。大部分のメンテナーはこれらのルー
    97 + に従っていることを期待されています。大部分のメンテナはこれらのルー
    98 ルに従っているものだけを受け付け、多くの人は正しいスタイルのコード
    99 だけをレビューします。
    100
    101 @@ -168,16 +170,16 @@ Linux カーネルソースツリーは幅広い範囲のドキュメントを
    102 支援してください。
    103
    104 Documentation/ManagementStyle
    105 - このドキュメントは Linux カーネルのメンテナー達がどう行動するか、
    106 + このドキュメントは Linux カーネルのメンテナ達がどう行動するか、
    107 彼らの手法の背景にある共有されている精神について記述しています。こ
    108 れはカーネル開発の初心者なら（もしくは、単に興味があるだけの人でも）
    109 - 重要です。なぜならこのドキュメントは、カーネルメンテナー達の独特な
    110 + 重要です。なぜならこのドキュメントは、カーネルメンテナ達の独特な
    111 行動についての多くの誤解や混乱を解消するからです。
    112
    113 Documentation/stable_kernel_rules.txt
    114 このファイルはどのように stable カーネルのリリースが行われるかのルー
    115 ルが記述されています。そしてこれらのリリースの中のどこかで変更を取
    116 - り入れてもらいたい場合に何をすればいいかが示されています。
    117 + り入れてもらいたい場合に何をすれば良いかが示されています。
    118
    119 Documentation/kernel-docs.txt
    120 　　カーネル開発に付随する外部ドキュメントのリストです。もしあなたが
    121 @@ -218,9 +220,9 @@ web サイトには、コードの構成、サブシステム、現在存在す
    122 ここには、また、カーネルのコンパイルのやり方やパッチの当て方などの間接
    123 的な基本情報も記述されています。
    124
    125 -あなたがどこからスタートしてよいかわからないが、Linux カーネル開発コミュ
    126 +あなたがどこからスタートして良いかわからないが、Linux カーネル開発コミュ
    127 ニティに参加して何かすることをさがしている場合には、Linux kernel
    128 -Janitor's プロジェクトにいけばよいでしょう -
    129 +Janitor's プロジェクトにいけば良いでしょう -
    130 http://janitor.kernelnewbies.org/
    131 ここはそのようなスタートをするのにうってつけの場所です。ここには、
    132 Linux カーネルソースツリーの中に含まれる、きれいにし、修正しなければな
    133 @@ -243,7 +245,7 @@ Linux カーネルソースツリーの中に含まれる、きれいにし、
    134 自己参照方式で、索引がついた web 形式で、ソースコードを参照することが
    135 できます。この最新の素晴しいカーネルコードのリポジトリは以下で見つかり
    136 ます-
    137 - http://sosdg.org/~coywolf/lxr/
    138 + http://sosdg.org/~qiyong/lxr/
    139
    140 開発プロセス
    141 -----------------------
    142 @@ -265,9 +267,9 @@ Linux カーネルの開発プロセスは現在幾つかの異なるメイン
    143 以下のとおり-
    144
    145 - 新しいカーネルがリリースされた直後に、2週間の特別期間が設けられ、
    146 - この期間中に、メンテナー達は Linus に大きな差分を送ることができま
    147 - す。このような差分は通常 -mm カーネルに数週間含まれてきたパッチで
    148 - す。 大きな変更は git(カーネルのソース管理ツール、詳細は
    149 + この期間中に、メンテナ達は Linus に大きな差分を送ることができます。
    150 + このような差分は通常 -mm カーネルに数週間含まれてきたパッチです。
    151 + 大きな変更は git(カーネルのソース管理ツール、詳細は
    152 http://git.or.cz/ 参照) を使って送るのが好ましいやり方ですが、パッ
    153 チファイルの形式のまま送るのでも十分です。
    154
    155 @@ -285,6 +287,10 @@ Linux カーネルの開発プロセスは現在幾つかの異なるメイン
    156 に安定した状態にあると判断したときにリリースされます。目標は毎週新
    157 しい -rc カーネルをリリースすることです。
    158
    159 + - 以下の URL で各 -rc リリースに存在する既知の後戻り問題のリスト
    160 + が追跡されます-
    161 + http://kernelnewbies.org/known_regressions
    162 +
    163 - このプロセスはカーネルが 「準備ができた」と考えられるまで継続しま
    164 す。このプロセスはだいたい 6週間継続します。
    165
    166 @@ -331,8 +337,8 @@ Andrew は個別のサブシステムカーネルツリーとパッチを全て
    167 linux-kernel メーリングリストで収集された多数のパッチと同時に一つにま
    168 とめます。
    169 このツリーは新機能とパッチが検証される場となります。ある期間の間パッチ
    170 -が -mm に入って価値を証明されたら、Andrew やサブシステムメンテナが、メ
    171 -インラインへ入れるように Linus にプッシュします。
    172 +が -mm に入って価値を証明されたら、Andrew やサブシステムメンテナが、
    173 +メインラインへ入れるように Linus にプッシュします。
    174
    175 メインカーネルツリーに含めるために Linus に送る前に、すべての新しいパッ
    176 チが -mm ツリーでテストされることが強く推奨されます。
    177 @@ -460,7 +466,7 @@ MAINTAINERS ファイルにリストがありますので参照してくださ
    178 せん-
    179 彼らはあなたのパッチの行毎にコメントを入れたいので、そのためにはそうす
    180 るしかありません。あなたのメールプログラムが空白やタブを圧縮しないよう
    181 -に確認した方がいいです。最初の良いテストとしては、自分にメールを送って
    182 +に確認した方が良いです。最初の良いテストとしては、自分にメールを送って
    183 みて、そのパッチを自分で当ててみることです。もしそれがうまく行かないな
    184 ら、あなたのメールプログラムを直してもらうか、正しく動くように変えるべ
    185 きです。
    186 @@ -507,14 +513,14 @@ MAINTAINERS ファイルにリストがありますので参照してくださ
    187 とも普通のことです。これはあなたのパッチが受け入れられないということで
    188 は *ありません*、そしてあなた自身に反対することを意味するのでも *ありま
    189 せん*。単に自分のパッチに対して指摘された問題を全て修正して再送すれば
    190 -いいのです。
    191 +良いのです。
    192
    193
    194 カーネルコミュニティと企業組織のちがい
    195 -----------------------------------------------------------------
    196
    197 カーネルコミュニティは大部分の伝統的な会社の開発環境とは異ったやり方で
    198 -動いています。以下は問題を避けるためにできるとよいことののリストです-
    199 +動いています。以下は問題を避けるためにできると良いことのリストです-
    200
    201 あなたの提案する変更について言うときのうまい言い方：
    202
    203 @@ -525,7 +531,7 @@ MAINTAINERS ファイルにリストがありますので参照してくださ
    204 - "以下は一連の小さなパッチ群ですが..."
    205 - "これは典型的なマシンでの性能を向上させます.."
    206
    207 - やめた方がいい悪い言い方：
    208 + やめた方が良い悪い言い方：
    209
    210 - このやり方で AIX/ptx/Solaris ではできたので、できるはずだ
    211 - 私はこれを20年もの間やってきた、だから
    212 @@ -575,10 +581,10 @@ Linux カーネルコミュニティは、一度に大量のコードの塊を
    213
    214 1) 小さいパッチはあなたのパッチが適用される見込みを大きくします、カー
    215 ネルの人達はパッチが正しいかどうかを確認する時間や労力をかけないか
    216 - らです。5行のパッチはメンテナがたった1秒見るだけで適用できます。し
    217 - かし、500行のパッチは、正しいことをレビューするのに数時間かかるかも
    218 - しれません(時間はパッチのサイズなどにより指数関数に比例してかかりま
    219 - す)
    220 + らです。5行のパッチはメンテナがたった1秒見るだけで適用できます。
    221 + しかし、500行のパッチは、正しいことをレビューするのに数時間かかるか
    222 + もしれません(時間はパッチのサイズなどにより指数関数に比例してかかり
    223 + ます)
    224
    225 小さいパッチは何かあったときにデバッグもとても簡単になります。パッ
    226 チを1個1個取り除くのは、とても大きなパッチを当てた後に(かつ、何かお
    227 @@ -587,23 +593,23 @@ Linux カーネルコミュニティは、一度に大量のコードの塊を
    228 2) 小さいパッチを送るだけでなく、送るまえに、書き直して、シンプルにす
    229 る(もしくは、単に順番を変えるだけでも)ことも、とても重要です。
    230
    231 -以下はカーネル開発者の Al Viro のたとえ話しです：
    232 +以下はカーネル開発者の Al Viro のたとえ話です：
    233
    234 "生徒の数学の宿題を採点する先生のことを考えてみてください、先
    235 - 生は生徒が解に到達するまでの試行錯誤をみたいとは思わないでしょ
    236 - う。先生は簡潔な最高の解をみたいのです。良い生徒はこれを知って
    237 + 生は生徒が解に到達するまでの試行錯誤を見たいとは思わないでしょ
    238 + う。先生は簡潔な最高の解を見たいのです。良い生徒はこれを知って
    239 おり、そして最終解の前の中間作業を提出することは決してないので
    240 す"
    241
    242 - カーネル開発でもこれは同じです。メンテナー達とレビューア達は、
    243 - 問題を解決する解の背後になる思考プロセスをみたいとは思いません。
    244 - 彼らは単純であざやかな解決方法をみたいのです。
    245 + カーネル開発でもこれは同じです。メンテナ達とレビューア達は、
    246 + 問題を解決する解の背後になる思考プロセスを見たいとは思いません。
    247 + 彼らは単純であざやかな解決方法を見たいのです。
    248
    249 あざやかな解を説明するのと、コミュニティと共に仕事をし、未解決の仕事を
    250 議論することのバランスをキープするのは難しいかもしれません。
    251 ですから、開発プロセスの早期段階で改善のためのフィードバックをもらうよ
    252 -うにするのもいいですが、変更点を小さい部分に分割して全体ではまだ完成し
    253 -ていない仕事を(部分的に)取り込んでもらえるようにすることもいいことです。
    254 +うにするのも良いですが、変更点を小さい部分に分割して全体ではまだ完成し
    255 +ていない仕事を(部分的に)取り込んでもらえるようにすることも良いことです。
    256
    257 また、でき上がっていないものや、"将来直す" ようなパッチを、本流に含め
    258 てもらうように送っても、それは受け付けられないことを理解してください。
    259 @@ -629,7 +635,7 @@ Linux カーネルコミュニティは、一度に大量のコードの塊を
    260 - テスト結果
    261
    262 これについて全てがどのようにあるべきかについての詳細は、以下のドキュメ
    263 -ントの ChangeLog セクションをみてください-
    264 +ントの ChangeLog セクションを見てください-
    265 "The Perfect Patch"
    266 http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
    267
    268 diff --git a/block/ll_rw_blk.c b/block/ll_rw_blk.c
    269 index ed39313..026cf24 100644
    270 --- a/block/ll_rw_blk.c
    271 +++ b/block/ll_rw_blk.c
    272 @@ -819,7 +819,6 @@ static int __blk_free_tags(struct blk_queue_tag *bqt)
    273 retval = atomic_dec_and_test(&bqt->refcnt);
    274 if (retval) {
    275 BUG_ON(bqt->busy);
    276 - BUG_ON(!list_empty(&bqt->busy_list));
    277
    278 kfree(bqt->tag_index);
    279 bqt->tag_index = NULL;
    280 @@ -931,7 +930,6 @@ static struct blk_queue_tag *__blk_queue_init_tags(struct request_queue *q,
    281 if (init_tag_map(q, tags, depth))
    282 goto fail;
    283
    284 - INIT_LIST_HEAD(&tags->busy_list);
    285 tags->busy = 0;
    286 atomic_set(&tags->refcnt, 1);
    287 return tags;
    288 @@ -982,6 +980,7 @@ int blk_queue_init_tags(struct request_queue *q, int depth,
    289 */
    290 q->queue_tags = tags;
    291 q->queue_flags |= (1 << QUEUE_FLAG_QUEUED);
    292 + INIT_LIST_HEAD(&q->tag_busy_list);
    293 return 0;
    294 fail:
    295 kfree(tags);
    296 @@ -1152,7 +1151,7 @@ int blk_queue_start_tag(struct request_queue *q, struct request *rq)
    297 rq->tag = tag;
    298 bqt->tag_index[tag] = rq;
    299 blkdev_dequeue_request(rq);
    300 - list_add(&rq->queuelist, &bqt->busy_list);
    301 + list_add(&rq->queuelist, &q->tag_busy_list);
    302 bqt->busy++;
    303 return 0;
    304 }
    305 @@ -1173,11 +1172,10 @@ EXPORT_SYMBOL(blk_queue_start_tag);
    306 **/
    307 void blk_queue_invalidate_tags(struct request_queue *q)
    308 {
    309 - struct blk_queue_tag *bqt = q->queue_tags;
    310 struct list_head *tmp, *n;
    311 struct request *rq;
    312
    313 - list_for_each_safe(tmp, n, &bqt->busy_list) {
    314 + list_for_each_safe(tmp, n, &q->tag_busy_list) {
    315 rq = list_entry_rq(tmp);
    316
    317 if (rq->tag == -1) {
    318 diff --git a/fs/locks.c b/fs/locks.c
    319 index c795eaa..494f250 100644
    320 --- a/fs/locks.c
    321 +++ b/fs/locks.c
    322 @@ -694,11 +694,20 @@ EXPORT_SYMBOL(posix_test_lock);
    323 * Note: the above assumption may not be true when handling lock requests
    324 * from a broken NFS client. But broken NFS clients have a lot more to
    325 * worry about than proper deadlock detection anyway... --okir
    326 + *
    327 + * However, the failure of this assumption (also possible in the case of
    328 + * multiple tasks sharing the same open file table) also means there's no
    329 + * guarantee that the loop below will terminate. As a hack, we give up
    330 + * after a few iterations.
    331 */
    332 +
    333 +#define MAX_DEADLK_ITERATIONS 10
    334 +
    335 static int posix_locks_deadlock(struct file_lock *caller_fl,
    336 struct file_lock *block_fl)
    337 {
    338 struct list_head *tmp;
    339 + int i = 0;
    340
    341 next_task:
    342 if (posix_same_owner(caller_fl, block_fl))
    343 @@ -706,6 +715,8 @@ next_task:
    344 list_for_each(tmp, &blocked_list) {
    345 struct file_lock *fl = list_entry(tmp, struct file_lock, fl_link);
    346 if (posix_same_owner(fl, block_fl)) {
    347 + if (i++ > MAX_DEADLK_ITERATIONS)
    348 + return 0;
    349 fl = fl->fl_next;
    350 block_fl = fl;
    351 goto next_task;
    352 diff --git a/fs/proc/array.c b/fs/proc/array.c
    353 index ee4814d..20d7ae4 100644
    354 --- a/fs/proc/array.c
    355 +++ b/fs/proc/array.c
    356 @@ -351,7 +351,8 @@ static cputime_t task_utime(struct task_struct *p)
    357 }
    358 utime = (clock_t)temp;
    359
    360 - return clock_t_to_cputime(utime);
    361 + p->prev_utime = max(p->prev_utime, clock_t_to_cputime(utime));
    362 + return p->prev_utime;
    363 }
    364
    365 static cputime_t task_stime(struct task_struct *p)
    366 @@ -366,7 +367,8 @@ static cputime_t task_stime(struct task_struct *p)
    367 stime = nsec_to_clock_t(p->se.sum_exec_runtime) -
    368 cputime_to_clock_t(task_utime(p));
    369
    370 - return clock_t_to_cputime(stime);
    371 + p->prev_stime = max(p->prev_stime, clock_t_to_cputime(stime));
    372 + return p->prev_stime;
    373 }
    374 #endif
    375
    376 diff --git a/fs/splice.c b/fs/splice.c
    377 index e95a362..02c39ae 100644
    378 --- a/fs/splice.c
    379 +++ b/fs/splice.c
    380 @@ -1390,10 +1390,10 @@ static int pipe_to_user(struct pipe_inode_info *pipe, struct pipe_buffer *buf,
    381 if (copy_to_user(sd->u.userptr, src + buf->offset, sd->len))
    382 ret = -EFAULT;
    383
    384 + buf->ops->unmap(pipe, buf, src);
    385 out:
    386 if (ret > 0)
    387 sd->u.userptr += ret;
    388 - buf->ops->unmap(pipe, buf, src);
    389 return ret;
    390 }
    391
    392 diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
    393 index b126c6f..d26bbb0 100644
    394 --- a/include/linux/blkdev.h
    395 +++ b/include/linux/blkdev.h
    396 @@ -356,7 +356,6 @@ enum blk_queue_state {
    397 struct blk_queue_tag {
    398 struct request **tag_index; /* map of busy tags */
    399 unsigned long *tag_map; /* bit map of free/busy tags */
    400 - struct list_head busy_list; /* fifo list of busy tags */
    401 int busy; /* current depth */
    402 int max_depth; /* what we will send to device */
    403 int real_max_depth; /* what the array can hold */
    404 @@ -451,6 +450,7 @@ struct request_queue
    405 unsigned int dma_alignment;
    406
    407 struct blk_queue_tag *queue_tags;
    408 + struct list_head tag_busy_list;
    409
    410 unsigned int nr_sorted;
    411 unsigned int in_flight;
    412 diff --git a/include/linux/sched.h b/include/linux/sched.h
    413 index 313c6b6..f509fbd 100644
    414 --- a/include/linux/sched.h
    415 +++ b/include/linux/sched.h
    416 @@ -1022,6 +1022,7 @@ struct task_struct {
    417
    418 unsigned int rt_priority;
    419 cputime_t utime, stime;
    420 + cputime_t prev_utime, prev_stime;
    421 unsigned long nvcsw, nivcsw; /* context switch counts */
    422 struct timespec start_time; /* monotonic time */
    423 struct timespec real_start_time; /* boot based time */
    424 diff --git a/kernel/fork.c b/kernel/fork.c
    425 index 33f12f4..f299d45 100644
    426 --- a/kernel/fork.c
    427 +++ b/kernel/fork.c
    428 @@ -1045,6 +1045,8 @@ static struct task_struct *copy_process(unsigned long clone_flags,
    429
    430 p->utime = cputime_zero;
    431 p->stime = cputime_zero;
    432 + p->prev_utime = cputime_zero;
    433 + p->prev_stime = cputime_zero;
    434
    435 #ifdef CONFIG_TASK_XACCT
    436 p->rchar = 0; /* I/O counter: bytes read */
    437 diff --git a/kernel/futex_compat.c b/kernel/futex_compat.c
    438 index 2c2e295..f938c23 100644
    439 --- a/kernel/futex_compat.c
    440 +++ b/kernel/futex_compat.c
    441 @@ -29,6 +29,15 @@ fetch_robust_entry(compat_uptr_t *uentry, struct robust_list __user **entry,
    442 return 0;
    443 }
    444
    445 +static void __user *futex_uaddr(struct robust_list *entry,
    446 + compat_long_t futex_offset)
    447 +{
    448 + compat_uptr_t base = ptr_to_compat(entry);
    449 + void __user *uaddr = compat_ptr(base + futex_offset);
    450 +
    451 + return uaddr;
    452 +}
    453 +
    454 /*
    455 * Walk curr->robust_list (very carefully, it's a userspace list!)
    456 * and mark any locks found there dead, and notify any waiters.
    457 @@ -75,11 +84,13 @@ void compat_exit_robust_list(struct task_struct *curr)
    458 * A pending lock might already be on the list, so
    459 * dont process it twice:
    460 */
    461 - if (entry != pending)
    462 - if (handle_futex_death((void __user *)entry + futex_offset,
    463 - curr, pi))
    464 - return;
    465 + if (entry != pending) {
    466 + void __user *uaddr = futex_uaddr(entry,
    467 + futex_offset);
    468
    469 + if (handle_futex_death(uaddr, curr, pi))
    470 + return;
    471 + }
    472 if (rc)
    473 return;
    474 uentry = next_uentry;
    475 @@ -93,9 +104,11 @@ void compat_exit_robust_list(struct task_struct *curr)
    476
    477 cond_resched();
    478 }
    479 - if (pending)
    480 - handle_futex_death((void __user *)pending + futex_offset,
    481 - curr, pip);
    482 + if (pending) {
    483 + void __user *uaddr = futex_uaddr(pending, futex_offset);
    484 +
    485 + handle_futex_death(uaddr, curr, pip);
    486 + }
    487 }
    488
    489 asmlinkage long
    490 diff --git a/kernel/lockdep.c b/kernel/lockdep.c
    491 index 734da57..42ae4a5 100644
    492 --- a/kernel/lockdep.c
    493 +++ b/kernel/lockdep.c
    494 @@ -1521,7 +1521,7 @@ cache_hit:
    495 }
    496
    497 static int validate_chain(struct task_struct *curr, struct lockdep_map *lock,
    498 - struct held_lock *hlock, int chain_head)
    499 + struct held_lock *hlock, int chain_head, u64 chain_key)
    500 {
    501 /*
    502 * Trylock needs to maintain the stack of held locks, but it
    503 @@ -1534,7 +1534,7 @@ static int validate_chain(struct task_struct *curr, struct lockdep_map *lock,
    504 * graph_lock for us)
    505 */
    506 if (!hlock->trylock && (hlock->check == 2) &&
    507 - lookup_chain_cache(curr->curr_chain_key, hlock->class)) {
    508 + lookup_chain_cache(chain_key, hlock->class)) {
    509 /*
    510 * Check whether last held lock:
    511 *
    512 @@ -1576,7 +1576,7 @@ static int validate_chain(struct task_struct *curr, struct lockdep_map *lock,
    513 #else
    514 static inline int validate_chain(struct task_struct *curr,
    515 struct lockdep_map *lock, struct held_lock *hlock,
    516 - int chain_head)
    517 + int chain_head, u64 chain_key)
    518 {
    519 return 1;
    520 }
    521 @@ -2450,11 +2450,11 @@ static int __lock_acquire(struct lockdep_map *lock, unsigned int subclass,
    522 chain_head = 1;
    523 }
    524 chain_key = iterate_chain_key(chain_key, id);
    525 - curr->curr_chain_key = chain_key;
    526
    527 - if (!validate_chain(curr, lock, hlock, chain_head))
    528 + if (!validate_chain(curr, lock, hlock, chain_head, chain_key))
    529 return 0;
    530
    531 + curr->curr_chain_key = chain_key;
    532 curr->lockdep_depth++;
    533 check_chain_key(curr);
    534 #ifdef CONFIG_DEBUG_LOCKDEP
    535 diff --git a/kernel/params.c b/kernel/params.c
    536 index 4e57732..5e5651f 100644
    537 --- a/kernel/params.c
    538 +++ b/kernel/params.c
    539 @@ -595,13 +595,16 @@ static void __init param_sysfs_builtin(void)
    540
    541 for (i=0; i < __stop___param - __start___param; i++) {
    542 char *dot;
    543 + size_t max_name_len;
    544
    545 kp = &__start___param[i];
    546 + max_name_len =
    547 + min_t(size_t, MAX_KBUILD_MODNAME, strlen(kp->name));
    548
    549 - /* We do not handle args without periods. */
    550 - dot = memchr(kp->name, '.', MAX_KBUILD_MODNAME);
    551 + dot = memchr(kp->name, '.', max_name_len);
    552 if (!dot) {
    553 - DEBUGP("couldn't find period in %s\n", kp->name);
    554 + DEBUGP("couldn't find period in first %d characters "
    555 + "of %s\n", MAX_KBUILD_MODNAME, kp->name);
    556 continue;
    557 }
    558 name_len = dot - kp->name;
    559 diff --git a/kernel/softlockup.c b/kernel/softlockup.c
    560 index 708d488..e557c44 100644
    561 --- a/kernel/softlockup.c
    562 +++ b/kernel/softlockup.c
    563 @@ -80,10 +80,11 @@ void softlockup_tick(void)
    564 print_timestamp = per_cpu(print_timestamp, this_cpu);
    565
    566 /* report at most once a second */
    567 - if (print_timestamp < (touch_timestamp + 1) ||
    568 - did_panic ||
    569 - !per_cpu(watchdog_task, this_cpu))
    570 + if ((print_timestamp >= touch_timestamp &&
    571 + print_timestamp < (touch_timestamp + 1)) ||
    572 + did_panic || !per_cpu(watchdog_task, this_cpu)) {
    573 return;
    574 + }
    575
    576 /* do not print during early bootup: */
    577 if (unlikely(system_state != SYSTEM_RUNNING)) {
    578 diff --git a/mm/filemap.c b/mm/filemap.c
    579 index 15c8413..14ca63f 100644
    580 --- a/mm/filemap.c
    581 +++ b/mm/filemap.c
    582 @@ -1312,7 +1312,7 @@ int filemap_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
    583
    584 size = (i_size_read(inode) + PAGE_CACHE_SIZE - 1) >> PAGE_CACHE_SHIFT;
    585 if (vmf->pgoff >= size)
    586 - goto outside_data_content;
    587 + return VM_FAULT_SIGBUS;
    588
    589 /* If we don't want any read-ahead, don't bother */
    590 if (VM_RandomReadHint(vma))
    591 @@ -1389,7 +1389,7 @@ retry_find:
    592 if (unlikely(vmf->pgoff >= size)) {
    593 unlock_page(page);
    594 page_cache_release(page);
    595 - goto outside_data_content;
    596 + return VM_FAULT_SIGBUS;
    597 }
    598
    599 /*
    600 @@ -1400,15 +1400,6 @@ retry_find:
    601 vmf->page = page;
    602 return ret | VM_FAULT_LOCKED;
    603
    604 -outside_data_content:
    605 - /*
    606 - * An external ptracer can access pages that normally aren't
    607 - * accessible..
    608 - */
    609 - if (vma->vm_mm == current->mm)
    610 - return VM_FAULT_SIGBUS;
    611 -
    612 - /* Fall through to the non-read-ahead case */
    613 no_cached_page:
    614 /*
    615 * We're only likely to ever get here if MADV_RANDOM is in
    616 diff --git a/mm/page-writeback.c b/mm/page-writeback.c
    617 index 4472036..97ddc58 100644
    618 --- a/mm/page-writeback.c
    619 +++ b/mm/page-writeback.c
    620 @@ -672,8 +672,10 @@ retry:
    621
    622 ret = (*writepage)(page, wbc, data);
    623
    624 - if (unlikely(ret == AOP_WRITEPAGE_ACTIVATE))
    625 + if (unlikely(ret == AOP_WRITEPAGE_ACTIVATE)) {
    626 unlock_page(page);
    627 + ret = 0;
    628 + }
    629 if (ret || (--(wbc->nr_to_write) <= 0))
    630 done = 1;
    631 if (wbc->nonblocking && bdi_write_congested(bdi)) {
    632 diff --git a/mm/shmem.c b/mm/shmem.c
    633 index fcd19d3..95558e4 100644
    634 --- a/mm/shmem.c
    635 +++ b/mm/shmem.c
    636 @@ -916,6 +916,21 @@ static int shmem_writepage(struct page *page, struct writeback_control *wbc)
    637 struct inode *inode;
    638
    639 BUG_ON(!PageLocked(page));
    640 + /*
    641 + * shmem_backing_dev_info's capabilities prevent regular writeback or
    642 + * sync from ever calling shmem_writepage; but a stacking filesystem
    643 + * may use the ->writepage of its underlying filesystem, in which case
    644 + * we want to do nothing when that underlying filesystem is tmpfs
    645 + * (writing out to swap is useful as a response to memory pressure, but
    646 + * of no use to stabilize the data) - just redirty the page, unlock it
    647 + * and claim success in this case. AOP_WRITEPAGE_ACTIVATE, and the
    648 + * page_mapped check below, must be avoided unless we're in reclaim.
    649 + */
    650 + if (!wbc->for_reclaim) {
    651 + set_page_dirty(page);
    652 + unlock_page(page);
    653 + return 0;
    654 + }
    655 BUG_ON(page_mapped(page));
    656
    657 mapping = page->mapping;
    658 diff --git a/mm/slub.c b/mm/slub.c
    659 index addb20a..c1f2fda 100644
    660 --- a/mm/slub.c
    661 +++ b/mm/slub.c
    662 @@ -1501,28 +1501,8 @@ new_slab:
    663 page = new_slab(s, gfpflags, node);
    664 if (page) {
    665 cpu = smp_processor_id();
    666 - if (s->cpu_slab[cpu]) {
    667 - /*
    668 - * Someone else populated the cpu_slab while we
    669 - * enabled interrupts, or we have gotten scheduled
    670 - * on another cpu. The page may not be on the
    671 - * requested node even if __GFP_THISNODE was
    672 - * specified. So we need to recheck.
    673 - */
    674 - if (node == -1 ||
    675 - page_to_nid(s->cpu_slab[cpu]) == node) {
    676 - /*
    677 - * Current cpuslab is acceptable and we
    678 - * want the current one since its cache hot
    679 - */
    680 - discard_slab(s, page);
    681 - page = s->cpu_slab[cpu];
    682 - slab_lock(page);
    683 - goto load_freelist;
    684 - }
    685 - /* New slab does not fit our expectations */
    686 + if (s->cpu_slab[cpu])
    687 flush_slab(s, s->cpu_slab[cpu], cpu);
    688 - }
    689 slab_lock(page);
    690 SetSlabFrozen(page);
    691 s->cpu_slab[cpu] = page;