Linux

トーバルズ、Linux 7.1で2件のプルリクエストを差し戻し

「hackだ」と「ひどい話はやめろ」。Linus TorvaldsがLinux 7.1のmerge windowで、性格の違う2件のpull requestに同じ原則で拒否を突きつけている。いずれも「良かれと思って」書かれたコードだ。

情報の灯台

2026年4月15日

「hackだ」と「ひどい話はやめろ」。リーナス・トーバルズがLinux 7.1のマージウィンドウで、性格の違う2件のプルリクエストに同じ原則で拒否を突きつけている。いずれも「良かれと思って」書かれたコードだ。

「hackだ」と切り捨てられたパフォーマンス修正

最初に差し戻されたのは、監査サブシステムの性能回帰を潰すためのパッチだった。レッドハットのワイマン・ロンらが書き、クリスチャン・ブラウアーがVFSツリーから送った。着眼点そのものは正しい。高コア数のワークステーションやサーバーで監査機能が有効化されていると、fs_pwdへの参照取得のたびにpath_get()とpath_put()が呼ばれ、単一のpwd dentry lockにスピンロックの競合が集中する。コア数が増えるほど、この一点が細く絞られたボトルネックになっていた。

昔なら誰も気にしなかった経路が、今のハードウェアでは可視化される。これは数百コア時代の現実問題だ。パッチはcopy_fs_struct周りに新しいヘルパー群を追加して、不要なpath_get()とpath_put()を減らす、という方向性で書かれていた。

ここでトーバルズが止まった。

本当にこれは気に入らない。少なくともプルするのは遅らせるつもりだ。

問題の核心は、修正されたコードパスの歪みそのものにあった。copy_fs_structでは、path_get(&fs->root)でrootを増やしたすぐ次の行で、get_fs_pwd_pool_locked(old, &fs->pwd)を呼んでpwdだけをまったく別の方法でコピーしている。本来対称であるべきrootとpwdが、監査側の歴史的事情によって別扱いになっていた。トーバルズの苛立ちはこの非対称そのものに向かっていた。

監査コードがpwdとrootを異なって扱う、その唯一の理由は、監査のコードが歴史的に壊れていて、chroot環境を扱えないからだ。

監査側のミスを、監査を使わない人間にまで押し付ける構造になっている、というのが彼の読みだ。カーネルの共通パスに、本来監査の内部でだけ閉じているべき歪みが漏れ出してきている。トーバルズは解決策を持っていない、とも明言している。そのうえで方針だけは示した。ひとつめ、監査はそもそも「pwdだけが特別」という前提で考え始めたのが間違い。ふたつめ、監査はstruct pathへの参照を取るのではなく、struct fs_structを丸ごと借りて持つべきだ。

「借りる」という発想

トーバルズが代替案として投げたのは、「構造体を借りる」モデルと呼べる設計だった。新しいstruct audit_borrow_structを用意し、そこからstruct fs_structへのポインタを持たせる。監査側は全体を「借りている」だけで、コアのパス処理コードは一切変わらない。set_fs_root()、set_fs_pwd()、chroot_fs_refs()の3か所で、現在借りている側のリストを同期すればいい。そうすれば、監査がrootパスまできちんと持つようになり、現状の「rootは常にグローバルルートだ」と思い込んでいる振る舞いすら改善される、と彼は書いている。

大文字を並べて怒鳴りながら、最後は「頼むから考えてみてくれ」と頭を下げる。トーバルズの文章は、怒りと礼儀が同じ段落に同居する独特の呼吸を持っている。ブラウアーはこの指摘に同意し、当該部分をプルリクエストから落とすことに合意した。本文ごと取り下げられた形だ。

監査という「例外的な利用者」のために、全員が通る幹線道路を曲げるな。古典的なUnix的美学がここで効いている。良かれと思って書かれたコードほど、誰の重荷になるかを問い直す価値がある、という冷たい教訓でもある。

「余計なことを聞くな」

二件目はもっと短く、もっと直接的だった。RCU関連で提案されたBOOTPARAM_RCU_STALL_PANICというKconfigオプションだ。コンパイル時に、RCU停止が起きたときにカーネルをパニックさせる挙動をデフォルトにするかどうか、を選ばせる。高可用性システムでは、RCU停止を検知したら即座にカーネルをパニック・再起動させて自動復旧に回したい、という要求は実在する。カーネルブート時にsysctlを設定するユーザー空間の手間を省ける、という建前もあった。

トーバルズはこの新しいKconfigオプションそのものを嫌った。

もうたくさんだ。こういうひどい話はやめてくれ。

彼の論理はシンプルだ。カーネル設定の段階は、自分でカーネルをビルドしようとする人間にとって最大の苦痛の一つであり、「そこで選ばせるな」が大原則だという。同じ振る舞いは、ブート時のカーネルコマンドラインでsysctl.kernel.panic_on_rcu_stall=trueと渡せば今すぐ実現できる。追加のKconfigは一行も要らない。

そういう望みを持つ人間はsysctlを使えばいい。我々は全員の生活を悪くしたりはしない。

トーバルズはさらに一歩踏み込んで、Kconfigファイルこそが「普通のユーザー」への最も見える窓口だと書いた。自作カーネルに挑戦する新規ユーザーが最初に触る場所であり、そこが意味不明な選択肢の墓場になれば、Linuxの裾野が痩せ細る。だから彼は、Kconfigオプションを追加したくなったら、まず「この古くて役に立たないオプションを代わりに消せないか」と自問しろ、とまで書いた。改善とは、機能を増やすことではなく、選択を減らすことだ。そういう哲学の表明だ。

議論の最後では、同じ挙動がsysctl.kernel.panic_on_rcu_stall=trueをブートパラメータに書くだけで実現できることが確認されている。つまり、問題を解決したいユーザーには最初から道があった。Kconfigを増やす必要は最初からなかった、ということになる。

「成熟したリーナス」を見るフォーラム

フォロニクスのフォーラムでは、この拒否の仕方そのものが話題になっていた。あるユーザーは「意外にも、今回は冷静だ」と書いた。別のユーザーは「リーナスは成熟してきた。叫ばなくても、同じくらい噛みつける」とコメントした。大文字の連打こそあるが、罵倒語は引用の中にすらない。怒りの温度は変わっていないのに、刃の当て方だけが静かになった、という印象を多くの読者が受け取っている。

全員に影響するデフォルトの話と、一部の利用者のための最適化の話。この2件に共通しているのは、どちらも「例外を全体に流し込むな」という同じ原則で裁かれている点だ。「構造体を借りる」設計の提案も、sysctlで済む話にKconfigを増やすなという説教も、出発点は同じ場所にある。カーネルは全員の持ち物であり、誰かの特殊事情の受け皿ではない。

トーバルズの最後の一言は、記憶に残る短さだった。