今週のLKML - Emacs ひきこもり生活

forkbomb killer

パッチについて

http://permalink.gmane.org/gmane.linux.kernel.mm/60317

こんな簡単なコマンドを実行したとする。(やらないでね)

# forkbomb(){ forkbomb|forkbomb & } ; forkbomb

するとまぁ見てわかる通り、あっというまにプロセスが大増殖する。

説明はこのpatchがくわしい。
http://permalink.gmane.org/gmane.linux.kernel.mm/60318

読んでみて簡単に翻訳してみると…

forkbomb の問題は二種類にわけられる。

プロセスの数でメモリを圧迫してシステムを不安定に
大量のメモリを食って大量のswapoutを起こしてシステムを遅くする

1番は ulimit で、2番は cgroup でメモリ量を制限したり overcommit_memory をいじったりすることで一応の対処はできる。

しかし、 1番のulimitだと、 forkbomb を起こしてしまったユーザはすでに ulimit にかかっているのでなにもできなくて他のadminユーザ頼りになる。もちろん root が forkbomb しちゃったらもうどうしようもない。

2番の cgroup の方はあらかじめプロセスをグループにいれておかないといけないわけで…「想定外」のことが起こると大変なことになってしまうわけで…。

ということで、 OOM が走る時に「最近起動して大量にメモリを食っているプロセスツリー(=多分 forkbomb)をkillする」というのがこのパッチになる。

このパッチを入れてKConfigで有効にすると

/sys/kernel/mm/oom/mm_tracking_enabled と /sys/kernel/mm/oom/mm_tracking_reset_interval_msecs という sys ファイルができる。前者は見てわかる通りにこの機能を有効にするかどうか、後者は「最近機動したプロセス」の追跡をリセットする間隔になる。

システムの起動からずーっとリセットもせずに追跡はできない。ここで設定した間隔ごとに

プロセス数
kswapd が走った回数
alloc stall(メモリ要求)の回数

をチェックする。これが前回と比べて増えていなければ、前回までの結果をリセットしてしまう。

と、いうものだがもちろん「追跡」するために fork/vfork/exit あたりには overhead が必要になる。

議論

http://permalink.gmane.org/gmane.linux.kernel.mm/60326

forkbomb なんてめったに起こらないことのために、しょっちゅう起こるforkのたびに overhead ってのはどうなのかね?
- forkbomb が起こった時は物理的にリセットしなくてはいけないことが多く、ネットワークのむこうだとかだとしんどい
サーバとかだとアプリケーションは厳選されてるんじゃ?
- 人の手では100%はないよね。
- システムが普通の人の作業でこわれる、というのはあってはならない。

http://permalink.gmane.org/gmane.linux.kernel.mm/60406

そんなんは userland で kill(-1,SIGSTOP)すればいいよ
- http://permalink.gmane.org/gmane.linux.kernel.mm/60407
- OOM が動いてるような状況でも*本当に*それが動くのか?

APMの削除?

http://comments.gmane.org/gmane.linux.kernel/1117266

2006年のVistaのリリースではもうAPMサポートなくなってしまったし、これ以上APMが必要なノートに出会うこともないだろうし、削除しようというパッチ。

http://permalink.gmane.org/gmane.linux.kernel/1117299

80年代までしか使われていなかったようなもののサポートもまだ残っているし、消す必要もないのでは? 古いコードを残しておくことは(実際にはテストしないし)そんなに手間ではない、ということらしい。特にAPMはx86に深く食いこんでメンテの邪魔になるような規模ではないわけだし。

削除するなら

CONFIG_APM を CONFIG_EXPERT の下にうつして、誰か文句言わないか反応を見る
WARN() を使って、「APM なくなるかもよ。どうしても必要なら言ってね。」というような警告を出す

という手順をとるべき、らしい。

http://permalink.gmane.org/gmane.linux.kernel/1117824

こんなスケジュールでどうだい?という提案

2.6.39:
- 2.6.42 で削除されると feature-removal.txt に書く
- CONFIG_EXPERT の下に移す
2.6.40, 2.6.41
- 実行時に WARN() する
2.6.42:
- 削除

http://permalink.gmane.org/gmane.linux.kernel/1117814

そもそも、なぜAPMを削除したいか、について。APMがいらないなら、APMサポートなしでコンパイルしたら?という意見に対して。 APMのみのラップトップで cpuidle が動くか、のようなテストをしたくない、らしい。

Acked-By がついていたりもするし、メンテナさんが見つかったりテストする人が出てこなければAPMは削除されるんですかね。

overlay filesystem

http://comments.gmane.org/gmane.linux.file-systems/52078

リードオンリーなファイルシステムの上に、リードライト可能なファイルシステムをかぶせることを実現するファイルシステム。ようするに、 LiveCD とかで「リードオンリーなCD上のファイルシステム」の上に「USBメモリとかさして作った書きこみ可能な領域」をかぶせて、LiveCDだけど普通のマシンみたいに書きこみもできちゃうよ、ということを実現する。

unionfs と違って、一度ファイルを open してしまえば、後はその「上のファイルシステム」か「下のファイルシステム」に直接オペレーションがとぶようになるので開けた後のオーバーヘッドが少ないし、実装もシンプルになる。

http://permalink.gmane.org/gmane.linux.kernel/1116300

ドキュメントはこのパッチ。

http://permalink.gmane.org/gmane.linux.kernel/1116347

もっとファイルを構造化しなよ、と Linus からつっこみ。