11月版　怒りのLinus――メンテナにかんしゃく玉爆発

小崎資広
2009/12/10

怒りのLinus――Linuxコミュニティにおけるメンテナの役割とは

「You're full of sh*t.」

　おやおや、けんのんな雰囲気ですね。Linusがまたかんしゃくを爆発させているようです。いったい何が起きたのでしょうか？ 話はその2日ほど前にさかのぼります。

　Dmitry Torokhovは「Please consider reverting 7d930bc33653d5592dc386a76a38f39c2e962344」と題するメールを投稿しました。彼のbisect（問題がどのリビジョンで発生したのかを探索すること）により、上記パッチがカーネルパニックを引き起こしていることが分かったというのです。そのため彼は、元パッチの関係者をCcしつつ、Linusに当該パッチのrevertを要請します。

　それに対してDavid Miller（ネットワーク全体のメンテナ）が素早く、「ああ、それね。もう修正は僕のツリーにあるし、今晩Linusに送られるはずだよ」と返事をしました。

　ところがこのメールに対して、意外なところから不平が上がりました。Marcel Holtmann（Bluetoothサブシステムのメンテナ）が、「できたら、サブシステムメンテナをスルーするのはやめないか。ちょっと最近、こういうケースが多過ぎるように思うんだ」といい出したのです（注4）。

　Johannes Berg（CFG80211サブシステムのメンテナ）もこれに応じて「これはちょっと大げさないい方だけど、僕はこの問題（筆者注：自分が知らない間にコードが変えられてしまう問題）に何度も何度もすごく煩わされてきたんだ。ああ、もちろん、これは君（Dmitry）にいってるんじゃないよ。いろいろな人がしばしば、mainlineへのマージフローでの“上位”の人（この場合はLinus）にrevertを依頼してるってこと。それにメールの文面も、『xxをrevertしてくれ』というようなトゲトゲした内容ではなく、『xxという修正に問題を見つけたので……』という感じの、少しだけ礼儀に配慮した文面が望ましいと思うし、コミュニケーションを助けると思うんだよ」とやんわりと不満を表明しました。

　その上でさらに「誤解しないようにあらかじめいっておくけど、このコミットは確かに間違ってる。私のテストが完全ではなく、起きてはいけないことが起きてしまった。明確に私のミスであり、私はこれについて謝罪したい」とフォローしました。

　Marcelがさらにそれに答え「全く同意します。最近そういう事例が多過ぎると思うし、そういうのはやめるべきです。そうでなければ、サブシステムメンテナなんて必要ありません。あらゆるパッチをLinusに直接送り、彼がすべてのコードのすべての行をレビューすればいいってことになってしまいます。これは、なぜtarballの中のMAINTAINERSファイルに適切な連絡先がリストアップされているかという理由でもあります。Dave（David Miller）やLinusは、このバグについてコメントを求める適切な人ではありません」と、サブシステムメンテナの立場から見た望ましいバグ報告の方法について説明をしました。

　こんなふうに、当事者同士がお互いに「次から気を付けるよ」といい合って、そのまま話が終わりそうに見えました。しかしここで、突如議論に乱入してきて、あり得ない勢いでMarcelとJohannesを罵倒（ばとう）し始めた人がいます。Linusです。これが冒頭の発言ですね。彼は続けて、なぜそんなに怒っているのか、理由を説明します。

バグはバグなんだ。それはrevertされるべきで、それを混入させたヤツはそれを恥じるべきなんだ。僕がコードのすべての行をレビューする必要はまったくない。revertはただのrevertにすぎないからだ。 　こういうタイミング（要するに-rc1より後ってこと。いまはrc5なんだぜ？ 覚えてるか？）では、単にrevertするのはすごく正しい方法なんだ。あのコミットはクソで、それが修正したよりも多くの問題を引き起こした。ああ、そうだ。僕は腹を立てているんだ。この件では以前にも同じbisect結果が報告されており、そのとき僕もデバッグに時間を費やし、Johannesに情報を送ったんだ。ヤツがbisect結果を無視するからだ。そしてヤツは再び無視し、それはほかの人々がまたもやbisectに時間を費やす事態を招いた。そればかりか今度は不平を並べ始めたんだ。 　いいか、人に不平をいう前に自分自身を鏡で見てみろ。もし君がバグってるコミットを書き、誰かがそれをbisectしてくれたならば、女々しく泣き言をいう代わりに、 a）期待に応え、revertする b）その人に感謝する、「あなたが」混入させたバグを見つけてくれたことを c）自分自身を恥じる とするべきなんだ。 　いいかい、メンテナシップはオーナーシップとは違うものなんだ。メンテナシップは君がそのコードに責任があること、そして君がそうクレジットされることを意味する。けど、問題が発生しているときに、コードの所有権を主張することなどできやしないし、されるべきでもないんだ。もし、君がこれを理解できないというなら、君はもうメンテナじゃない！ 　バグを見つけてくれた人に見当違いの不平をぶつけるのはやめろ！

　Andrew Mortonはそれに応じつつ、なぜこのような、ある種のメンテナ軽視文化が生じているのかについて若干の補足を加えました。

問題は、サブシステムメンテナたちが全然頼りにならないことです。 　いま、私は2.6.32に入れるべき、そしてサブシステムメンテナたちが注意を払うべきと考えるパッチを17も保持しています。彼らはすでにパッチを（通常、最低2回は）見ているにもかかわらずグズグズしています。こんなのはよくあることなんです。 　それに加え、同じように無視されたクリティカルではないパッチを常時100から200個保持しています。その上、すべてのバグリポートが片方の耳から入り、反対の耳から出ていってしまうような状況です。何人かのサブシステムメンテナは良い仕事をしていますが、何人かはそうではないんです。おそらく、私は誰がそうであるかをリストアップできる唯一の人間です。 　不幸なことに、私よりも「リア充」な人々はサブシステムメンテナとしては頼みにならないんです。もし、問題が重症であるならば、メンテナをバイパスすることは賢明であり、デフォルトではそうあるべきです。

　2人とも、一見まっとうなことをいっているように聞こえますが、24時間いつメールしても5分で返事が返ってくるAndrewを基準にして「私よりリア充なヤツはunreliable」なんていわれると、周りも困ってしまいます。「テストをしてくれる人とバグを報告してくれる人は、デベロッパよりも偉い」というLKML文化がよく表れている事件ですね。

注4：Andrew Mortonなどごく一部の例外を除けば、Linus以外のメンテナはみんな「サブシステムメンテナ」といえます。けれど、ネットワーク周りはデバイスもプロトコルも多種多様で、サイズも大きすぎるため、一部のサブシステムメンテナに権限を委譲し、bluetoothとかwirelessといった個々のパッチは、一度David Millarに集約してからLinusに送るという、ちょっと異なる体制をとっていました。このあたりの権限の委譲範囲が明確でなかったことが、今回の論争の一因といえそうです。

お帰り！ ゼロページ

　mmap()やbrk()などのメモリ確保システムコールには、manページに書かれていない重要なお約束があります。それは「確保されたページはゼロ初期化してからユーザー空間に返さないといけない」ということです。

　カーネルは、自分が使わないページにどんなゴミが入っていても気にしないし、ユーザー空間アプリもmalloc()の戻りアドレスがゼロ初期化されていることなんて期待していません。にもかかわらずなぜこれが必要かというと、メモリを確保できるってことは、そのメモリを解放したプロセスが存在していたということを意味するからです。

　解放されたメモリには、クレジットカードの番号やパスワード、「いちゃいちゃうふふ」な内容の恥ずかしいメールやらが入っているかもしれません。悪意のあるプロセスがmmap/munmapを繰り返すだけで個人情報が収集できてしまうのは問題ですね。そういう事情もあり、典型的なLinuxデスクトップでは、「ゼロしか入ってないページ」を何千ページも持っています。大きめにバッファをmalloc()するアプリなんて山ほどありますからね。

　さて、世の中には賢い人がいて「そんなにゼロクリアされたページが多いなら、1つにまとめてしまおう。どうせ内容は全部同じだ」という発想で、中身がすべてゼロのページを共有する仕組みを作りました。これが、いわゆる「ゼロページ」です。

　これはとてもよくできた仕組みですが、マルチプロセッサ環境において潜在的な性能問題を抱えていました。マルチプロセッサ対応カーネルのスケーラビリティを向上させるためには、複数のプロセッサが1つのメモリアドレスに書き込みを行う状態を可能な限り避けなければいけません。そうでなければ、キャッシュコヒーレンシのためにお互いに相手のキャッシュを無効化してしまい、キャッシュヒット率が下がってしまうからです。

　2.6.24の時代（約2年前）に、Nick Pigginによりゼロページの参照カウンタ操作が上記の「キャッシュ追い出し祭り」を引き起こしていることが説明され、スケーラビリティ向上のため、ゼロページ機能が丸ごと削除されました。

　しかしながら、実はこの判断は良くなかったことが徐々に分かってきました。世の中には、少数ですが無視はできない数のゼロページに依存したアプリケーションがあり、定期的にLKMLにバグ報告が寄せられる結果になったのです。ユーザーからすると、いままでと同じアプリを使っているのに、カーネルをバージョンアップしたらOOM Killが発生するようになるわけですから納得いきません。

　こうした事態を受け、KAMEZAWA Hiroyuki、Hugh Dickinsにより、一から書き直された新しいゼロページがLKMLに投稿され、Linusの強い支持の下、あっという間にマージされました。新実装はゼロページのPFN（ページフレーム番号）を覚えておいて、ゼロページへの参照カウンタ操作の発生を防ぐ巧妙な実装になっています。

2/2

Index Linux Kernel Watch　11月版 　怒りのLinus――メンテナにかんしゃく玉爆発

Page 1 　スケジューラ改善、その後 　ext4ファイルシステム破損問題が解決、犯人は…… Page 2 　怒りのLinus――Linuxコミュニティにおけるメンテナの役割とは 　お帰り！ ゼロページ

連載 Linux Kernel Watch

---

Linux Squareフォーラム Linuxカーネル関連記事

	連載：Linux Kernel Watch（連載中） Linuxカーネル開発の現場ではさまざまな提案や議論が交わされています。その中からいくつかのトピックをピックアップしてお伝えします
	連載：Linuxファイルシステム技術解説 ファイルシステムにはそれぞれ特性がある。本連載では、基礎技術から各ファイルシステムの特徴、パフォーマンスを検証する
	特集：全貌を現したLinuxカーネル2.6［第1章］ エンタープライズ向けに刷新されたカーネル・コア ついに全貌が明らかになったカーネル2.6。6月に正式リリースされる予定の次期安定版カーネルの改良点や新機能を詳しく解説する
	特集：/procによるLinuxチューニング［前編］ /procで理解するOSの状態 Linuxの状態確認や挙動の変更で重要なのが/procファイルシステムである。/procの概念や/procを利用したOSの状態確認方法を解説する
	特集：仮想OS「User Mode Linux」活用法 Linux上で仮想的なLinuxを動かすUMLの仕組みからインストール／管理方法やIPv6などに対応させるカーネル構築までを徹底解説
	Linuxのカーネルメンテナは柔軟なシステム カーネルメンテナが語るコミュニティとIA-64 Linux IA-64 LinuxのカーネルメンテナであるBjorn Helgaas氏。同氏にLinuxカーネルの開発体制などについて伺った
	more

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）