Linux カーネルのメモリエラーハンドリング機能の開発

NEC ソリューションイノベータの堀口です。

2022 年 12 月 5、6 日に開催された Open Source Summit Japan 2022 において、 Current Status and Future of HWPOISON Subsystem というテーマで講演する機会が得られました。本記事では、この講演の発表内容を概説しつつ、私が日々取り組んでいるカーネル開発について紹介します。

HWPOISON とは

HWPOISON は Linux カーネルが備えているメモリエラーハンドリング機能を指す用語です。HWPOISON という言葉が、メモリエラーと関連しているというのは一見分かりにくいかもしれません。ハードウェアの故障によってメモリ上のデータが壊れるという現象が、例えばセキュリティ分野で言及されるキャッシュポイズニング攻撃のような、システムの継続を阻害するデータの注入と類推できるため、このような命名になったのだと思われます。

メモリエラーハンドリングは、稼働中の Linux システム上のメインメモリがハードウェア的な要因でデータ化けしたときに、OS がそれを早期に検出し、復旧処理を行うことで、メモリエラーのビジネスロジックへの影響を最小限に抑える処理を指します。

HWPOISON は、ハードウェア・ファームウェアから OS に故障を通知する機能を前提としています。ソフトウェアによる復旧が可能なメモリエラーを通知する機能を備えた CPU が市場に登場したのが 2008 年ごろで、ほぼ同時期に Linux カーネルにメモリエラーハンドリングの初期コードが導入されました。それ以降、筆者も開発に参加し、2014 年以降はカーネルメンテナとして関連するカーネル機能の強化・安定化に貢献し続けてきました。

本機能が登場した当初に比べて、2017、18 年ごろから海外の大手クラウド事業者を中心に、本機能へのパッチ投稿が増えた印象があります。私見ですが、この背景としては、ハードウェアが管理するエラー情報を OS に伝える手段を定める規格の ACPI APEI (ACPI Platform Error Interfaces) をサポートしたサーバが普及してきたというのがあるように思います。 ACPI APEI の疑似障害注入機能により、メモリエラーハンドリング機能のテストが容易になり、広くテストされるようになったことで、カーネルの問題点が多数検出されて報告や修正提案につながったのだと思います。これはとても素晴らしいことで、本講演を実施しようと思った動機として、この流れを受けてカーネル開発者向けに一度状況を整理して共有しておきたくなった、というのがあります。

講演内容

さて、それでは講演の内容について述べていきたいと思います。 講演の目的は、メモリエラーハンドリング機能の概要と最近の開発動向を知ってもらうことなので、この 2 つをそれぞれを前半と後半で解説しました。

メモリエラーハンドリング機能の概要

講演の前半の内容は、上記で述べてきた概要のより詳細に踏み込んだものです。 特に復旧処理の詳細は技術的に内容豊富で面白いところと言えるのですが、本記事では詳細は説明しないため、興味のある方は講演スライドの PDF を参照してください。ここでは、以下のスライドで説明したメモリエラーハンドリングの重要性について述べるにとどめておきます。

メモリエラーハンドリングは、例えばメモリ管理の中核であるメモリアロケータや、IO やネットワークといった、Linux を使う人の多くが知っているであろう基本的な機能ではないかもしれません。しかし、多数のサーバ・大量のメモリを抱えるデータセンターを運用する事業者にとって、可用性を高めることは経営に関わる重要課題で、ハードウェアエラーの中でも発生頻度が高いメモリエラーをハンドリングできることは非常に重要です。

最近の開発動向

講演の後半は、最近の開発トピックについて、それぞれ 1, 2 分で簡単に説明していくという構成を取りました。 これらはカーネル開発者や研究者からのフィードバックや新規参入したい若手開発者の興味を引くことを狙ったため、少し高度な内容になっています。一つ特徴をあげるとすると、最近の開発トピックの多くは (HWPOISON という機能単体に閉じた話というよりも) HWPOISON と関連の深い周辺機能との境界部分に関わるものが多いという点があります。

このスライドの開発トピックのリストを見てもらえれば分かるとおり、ページキャッシュ、Zero page、Hugepage, 不揮発性メモリ、メモリホットプラグ、といった Linux のメモリ管理機能内の別コンポーネントとの連携部分の話が多いです。Linux の利用者の中には、これらのコンポーネントについて耳にしたり、意識して使ったりしたことがある方も多いのではないかと思います。

メモリエラーハンドリングはこれらのメモリ管理機能に対して横断的な性質を持っているため、 今後新しいメモリの使い方をする機能が登場したり、既存のメモリ管理機能のメモリの使い方が変更されたりするたびに、新しい方式で使用しているメモリ上でのメモリエラーをきちんと扱えるか、どのような復旧処理が可能か、などを確認する必要があります。検討の結果、何も復旧処理はしない選択をすることもあります。

一番避けたいのは、中途半端に何かしようとしてできなかったあげく、カーネル内構造体の関係を壊したままシステムを継続してしまい、NULL ポインタ参照などの致命的な問題を起こしてしまうことです。そのために、カーネルの変化に伴うリグレッションを早期に検出し、HWPOISON のコードを追随していくとともに、そのプロセスを効率化していくことが重要で、私が普段パッチをレビューしたりテストコードを書く際にも、これらに注意を払うようにしています。

以上、簡単ながら本発表に関わるコミュニティ活動について説明しました。今後も機会があれば、カーネルコミュニティでの OSS 貢献活動について寄稿して行ければと思います。

執筆者

OSS貢献活動へ戻る