Tetsuo Handa
from-****@I-lov*****
2015年 9月 5日 (土) 00:22:57 JST
熊猫です。 昨年末からずっと、 Linux カーネルのメモリアロケータの挙動に起因した難題に 取り組んでいます。 memory cgroup を適切に使用していないと、ローカルの非特権 ユーザが Linux システムを簡単にロックアップさせることができるという問題です。 とてつもなく長い要約（ LWN.net の記事へのインデックス）が http://marc.info/?l=linux-kernel&m=143239201905479 にあります。 ＮＴＴオープンソースソフトウェアセンタに居た時は、主に Linux カーネルに 起因したトラブル、特にカーネルパニックや予期せぬ再起動／フリーズなどを 扱ってきました。上記の問題が発覚したことにより、予期せぬフリーズトラブルの 一部は上記の問題に起因しているのではないかと疑っています。（残念ながら、 サーバのリセットボタンを押す前にデバッグ情報を収集する方法を利用者に対して 伝える時間がありませんでしたので、実際に上記の問題に該当していたという 証拠は得られていません。） 現在、 Michal Hocko さんが __GFP_FS フラグを伴わないメモリ割り当て要求を 失敗させるようにすることで上記の問題に該当する可能性を減らすという試みを しています。しかし、 __GFP_FS フラグを伴わないメモリ割り当て要求を失敗 させる修正が意図せずに適用されてしまい、その結果システムが不安定になった という経緯があるため、このアプローチはとても慎重にテストされる必要が あります。熊猫が思うに、利用者は一度決めたカーネルバージョンをできる限り 長い間使い続けようとする傾向が強い（それが、熊猫がカーネルパニックや 予期せぬ再起動を多く扱うことになった一因でもある）ため、 Michal さんの アプローチでは、予期せぬ副作用が見つかった場合に修正を適用するのが 間に合わないと熊猫は考えています。（ SELinux などのカーネル内アクセス制御 機能を使うように、）先回りした対抗手段を使う方法であれば、利用者がカーネルの バージョンを決定するまでに間に合うと考えており、それが上記のパッチです。 __GFP_FS フラグを伴わないメモリ割り当て要求と言えば、 TOMOYO/AKARI/CaitSith を 含むカーネル内アクセス制御機能も、そのようなメモリ割り当て要求をしています。 これは、もし Michal さんのアプローチが採用された場合、ユーザ空間からのアクセス 要求が、利用可能なメモリがほとんど無い場合には ENOMEM エラーで失敗するように なることを意味しています。（ /proc/$pid/oom_score_adj では重要なプロセスを どうでもいいプロセスから保護することができるのに対し、）重要なプロセスによる アクセス要求がどうでもいいプロセスによるメモリ消費によって失敗させられるという 挙動は嬉しくないでしょう。全てのプロセスを適切な memory cgroup の中で動かす ことは、全てのプロセスを SELinux で制限するようなもので、簡単ではありません。 （ほとんどのシステムでは不可能でしょう。） 熊猫としては、メモリアロケータの挙動を変える（内部で __GFP_NORETRY が指定 されているかのように振る舞う）よりも、先回りした対抗手段を採用した上で 地道に呼び出し側を修正していく（呼び出し側に __GFP_NORETRY を追加していく） 方が好ましいと考えている訳です。 さてさて、どんな結末を迎えるのでしょうね？
TOMOYO
Fork