Magellan Linux

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

    Annotation 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 - (hide annotations) (download)
    Mon Jun 23 21:39:39 2008 UTC (15 years, 11 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 niro 658 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;