@naota344の今週のLKML

kernel LKML

今週は

  • Simultaneous cat and external keyboard input causing kernel panic
  • [PATCH] new cgroup controller "fork"
  • [RFC/GIT PULL] Linux KVM tool for v3.2
  • [ANNOUNCE] 3.1.0-ck1
  • [PATCH] KVM: Add wrapper script around QEMU to test kernels

Simultaneous cat and external keyboard input causing kernel panic

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

catコマンドだと思った…? 残念 かわいいネコちゃんでした!

なんと、ネコをノートPCのキーボードにのせて外部キーボードから入力していると…カーネルパニックした、というのです…! 実際に猫によってカーネルパニックしている様子の写真を http://people.debian.org/~timo/kernelpaniccat/ で見ることができます。



…………かわいい猫さんでしたね…。 LKMLでこんな写真があるとは・・・。

http://permalink.gmane.org/gmane.linux.kernel/1210845
http://permalink.gmane.org/gmane.linux.kernel/1210946

さて、それに対して Sys-Rqのせいかなーとか、 Cがcatnipじゃなかったせいだねー、とか 猫がいろんなものをぐちゃぐちゃにしてしまうのはよくあることだけれど、猫によるkernel panicが文書で報告されたのは初めてじゃないか!? Linuxは耐猫機構がないのでCVEを報告するべきじゃないかな! などと続いています。

LKMLでこんなことになるなんて……猫好きは世界的に変わらないものですかね… :)

[PATCH] new cgroup controller "fork"

http://permalink.gmane.org/gmane.linux.kernel.containers/21737

forkbombを防止する手段としてcgroupを使ったtask counter subsystemによるtask数の制限が提案されて、すでに-mm treeに入っています。 http://permalink.gmane.org/gmane.linux.kernel/1198795 そこにもうひとつ別に実装したものが提案されています。

このsubsystemはそのグループのfork数の上限を定めています。一度プロセスがforkすると設定した数がひとつ減らされ0になるとそれ以上forkできなくなります。これをCGIがひとつひとつに一時的なCGroupとして設定しておけば、リソースを食いつぶすforkbombをふせぐことができるようになります。

さて、このような提案がされたのですが、すでに-mm treeに上記のtask counter subsystemが入っていることにより、当初はかなり難色をしめされました。結局解決する問題がtask counter subsystemとかぶっているわけです…。

しかし、その後実装の違いから、たとえばクラックされた時に不要にforkされることをふせげることや、forkbomb検出後の「これ以上forkするな!」と「いくらでforkしてOK」の間がほしいよね、と言ったコメントがよせられています。

マージされるにせよおそらくはtask counter subsystemにマージされる形になるのではないかと思われます。ただ…patchの作者があまり積極的ではないようで……。

[RFC/GIT PULL] Linux KVM tool for v3.2

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

KVMの開発陣が実装しているKVMを使ったVMMであるNative KVM toolをLinuxカーネルにマージするかどうかの議論が白熱しています。開発陣としてはもともとの開発動機が、Linuxカーネル側とユーザランド側の開発ペースのへだたりやAPIの不整合・ヘッダファイルを多く共有することなどあげています。一方で、カーネルに関連するなら、とか言うならばJVMのコードがちょっとカーネルの機能を使うからってJVMでもマージするかい? makeもよく使うしマージするかい? などカーネルツリーにtoolをまぜるのか? などと応酬しています。

toolsディレクトリを見ると……よくわからないですねえ…。半分ぐらいはカーネルの機能をどうやって使うかのリファレンスコードになっているように思います。KVM toolもそういう感じでマージされてもいいかもしれません。結局…Linusの一声で決まってしまうのじゃないかな、と予想を…。

[ANNOUNCE] 3.1.0-ck1

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

主にデスクトップ用途を対象にシステムのレスポンス速度を改善するpatch ck-patchをgit.kernel.orgのアカウントが復旧するまで時間がかかりそうだから、新たな場所にホストしたよ、とアナウンスがありました。

[PATCH] KVM: Add wrapper script around QEMU to test kernels

http://permalink.gmane.org/gmane.linux.kernel/1210659
http://permalink.gmane.org/gmane.comp.emulators.qemu/123979

さらに…KVM native toolに対抗して…? QEMU側も、カーネルをシンプルにテストするために、QEMUを呼び出すシンプルなラッパスクリプトをLinuxカーネルツリーに入れようというpatchを出してきました…!

しかし・・・まあコマンドがシンプルになったにせよKVM tool側としてはQEMUがupdateじゃないし、さらにdistroもQEMUの最新をとってきてくれないし…という不満なようですからゆずれないところがありそうです。