Linux 7.0-rc6直前、EXT4に異例の大量バグ修正が投入された
Linux 7.0の正式リリースを4月中旬に控え、ファイルシステムの根幹を揺るがすバグ修正が一気に流れ込んでいる。
Linux 7.0の正式リリースを4月中旬に控え、ファイルシステムの根幹を揺るがすバグ修正が一気に流れ込んでいる。
EXT4メンテナが送った「重い」プルリクエスト
Linux 7.0-rc6のリリースを目前にした2026年3月29日、EXT4ファイルシステムのメンテナであるセオドア・ツォ（Theodore Ts'o）がリーナス・トーバルズに宛てたプルリクエストが、開発者コミュニティの目を引いている。
rc（リリース候補）の後半段階では、修正は小粒になるのが通例だ。だが今回の修正は「通常より重い」と評されている。19ファイル、455行の追加と115行の削除。安定化フェーズにしては、明らかに分量が多い。
Michael Larabel
修正内容を一つひとつ見ていくと、単なるコードの手直しではないことがわかる。メモリリーク、use-after-free、デッドロック、データ不整合——いずれもファイルシステムにとって致命的な領域のバグだ。
Syzkallerが暴いた「見えないバグ」たち
今回の修正群で目立つのは、Syzkaller（シスコーラー）によって発見された複数の問題だ。
Syzkallerとは、Googleが開発したカーネル向け自動ファジングツールだ。ランダムなシステムコールを大量に生成し、カーネルの異常動作を探し出す。人間のテストでは到達できないコードパスを、24時間体制で叩き続ける。
人間が書いたテストケースでは再現できないバグを、機械が無心に見つけ出す。地味だが、Linuxカーネルの品質を底支えしているのはこうした自動ファジングの仕組みだ。
修正リストには、エラーパスにおけるメモリリークの修正も含まれている。正常系では問題なく動いていても、異常系——つまり何かが失敗したときに、メモリが適切に解放されないケースがあった。サーバー環境で長期間稼働するシステムにとって、こうした「静かに蓄積する問題」は厄介な存在だ。
use-after-freeとデッドロック——根の深い問題
技術的に特に注目すべきは、use-after-freeバグの修正だろう。umount（アンマウント）処理と競合する状況で、すでに解放されたメモリ領域にアクセスしてしまう問題だ。
ファイルシステムの世界では、「タイミング」が全てを狂わせることがある。解放済みのinodeを再割り当てする際のレース条件がデッドロックを引き起こす問題も修正された。マルチコア環境が標準となった今、こうした並行処理の罠はむしろ増えている。
remountでdiscardを無効化した直後にumountを実行するとクラッシュする問題も含まれている。発見者として「Sashiko」の名前が記されている。
fast commitフラッシュパスでは、jinode構造体が完全に初期化される前にアクセスしてしまうクラッシュも修正された。ジャーナリングの高速化機能が、逆に不安定さの温床になっていたわけだ。
no-journalモードの落とし穴
見過ごされがちだが、ジャーナルなしモードに関する修正も2件含まれている。
一つは、fsync(2)が変更されたinodeをストレージに正しく書き出さない問題。ジャーナルがない環境でfsyncが信用できないとなれば、データベースやログ管理ツールにとっては致命的だ。
もう一つは、lazy itable初期化が有効な環境で、最近削除されたinodeを避けようとした際に未初期化のinodeをスキップしてしまい、e2fsck（ファイルシステム整合性チェックツール）が警告を出す問題。動作上は見えにくいが、データ整合性の信頼が揺らぐタイプのバグだ。
no-journalモードはパフォーマンスを重視する組み込みシステムや特殊用途で採用されることがある。メインストリームでは少数派だが、影響を受ける環境にとっては深刻な問題だ。
BUGマクロからの脱却という地道な改善
修正リストの中に、一見地味だが重要な変更がある。BUGマクロやWARNマクロをEFSCORRUPTED報告に置き換える作業だ。
BUGマクロが発動するとカーネルパニックが起きる。つまり、ファイルシステムの不整合を検知した瞬間にシステム全体が停止する。一方、EFSCORRUPTEDとしてエラーを報告する方式なら、問題のあるファイルシステムだけを切り離して処理を続行できる。
「問題を見つけたら即死」から、報告して生き延びる方向へ。この方向転換は、Linuxカーネル全体で進んでいる設計哲学の一部だ。サーバー運用者にとっては、一つのファイルシステムの破損がシステム全体を道連れにしない方が、はるかにありがたい。
18人の開発者が支える「地味な仕事」
今回のプルリクエストには、18人以上の開発者の名前が並んでいる。Ye Binが5件、Jan Karaが4件、Theodore Ts'oが3件。残りは各1件ずつだが、IBMのリテシュ・ハルジャニやHelen Koikeなど、企業所属の開発者も含まれている。
こうした修正は、新機能の追加と違ってニュースにはなりにくい。しかし、世界中のLinuxサーバーで最も広く使われているファイルシステムの信頼性を守っているのは、まさにこの種の作業だ。
MAINTAINERSファイルにEXT4のレビュアーが追加された点も見逃せない。これはメンテナンス体制の強化を意味し、レビューの質と速度の向上が期待できる。
Linux 7.0、安定へ向けた最終局面
Linux 7.0は2026年4月中旬の正式リリースが見込まれている。rc6は通常、最終盤の安定化段階だ。ここでこれだけの修正が入ること自体、Linux 7.0の開発サイクルが「いつもより活発」であることを物語っている。
トーバルズ自身がrc4の時点で、コミット数が通常より多い理由を「新しいメジャーバージョン番号の心理的効果」と分析していた。開発者が「せっかくの7.0だから」と積極的になっている可能性がある。
ただし、修正の量が多いことと不安定であることはイコールではない。むしろ、これだけの数のバグがリリース前に発見・修正されていることは、テスト体制の成熟を示している。Syzkallerのような自動ツールと、世界中の開発者による手動テストの両輪が回っている証拠だ。
EXT4は「枯れた技術」と見なされることもある。だが、枯れたからこそ見つかるバグがある。そしてそのバグを、455行の修正で静かに潰す人々がいる。
参照元
他参照
#Linux #EXT4 #カーネル #LinuxKernel #Linux7 #ファイルシステム #オープンソース #TheodoreTso #Syzkaller #バグ修正 #useafterfree #カーネル開発 #LinuxStorage #サーバー運用
