kmemleak を使用したカーネルメモリリークの検出と調査

カーネルがkmemleakによって検出するもの

Kmemleak Linuxカーネルのデバッグを支援し、孤立している可能性のあるメモリオブジェクトを検索します。このため、サポートされているメモリ割り当てを追跡し、スキャンしたメモリ領域からこれらのオブジェクトへの参照が検出されるかどうかを確認します。 到達可能と認識されなかったオブジェクトは、決定的なエラーとしてではなく、リークの可能性があるものとして表示されます。

あるカーネルモジュールがオブジェクトを予約した後、そのオブジェクトへの最後の参照を失い、メモリを解放しなかったと想像してみてください。kmemleak がその 参照検索 そのオブジェクトへの参照が一切なくなっている場合、それを不審なものとして報告することができます。この報告は、コード内の割り当てや想定されるライフサイクルを調査するための手がかりとなります。

この処理は、ガベージコレクタの到達可能性検索に似ていますが、そのクリーンアップ機能は引き継ぎません。Kmemleakは、報告されたオブジェクトを解放したり、コードを修復したりはしません。オブジェクトが実際に失われているかどうかは、その使用状況、所有関係、および予定されていた解放処理に基づいて判断する必要があります。

カーネルリークとは、カーネルコードまたはモジュールによって管理されているメモリに関するものです。PHP サービスやその他のユーザー空間プロセスにおけるリークは別の種類の不具合であり、kmemleak はそのヒープを調査しません。より広範な ホスティング運用におけるメモリリークの検出 そのため、プロセスデータやその他の診断ツールも検討の対象となる。

RAMの使用量が増加していることだけでは、 メモリリーク その場所も同様です。業務範囲の変更や、データの保持期間の延長も、要件に影響を与える可能性があります。したがって、時間的・機能的に範囲を限定できるプロセスから始めるのが合理的であり、それによってカーネルに関する疑念を的を絞って調査することができます。

なぜ報告された事例が「疑い例」のままであるのか

ポインタ値の検索では、プログラムが参照に割り当てたすべての意味を認識できるわけではありません。有効な参照がスキャン対象範囲外にある場合や、kmemleak が認識できないような場所に格納されている場合、依然として必要なオブジェクトが孤立しているように見えることがあります。これは起こりうる 誤報: その報告だけでは、承認が得られていないことを証明するものではありません。

その逆も起こり得ます。 コードでは参照として扱われていない数値が、たまたまポインタのようにオブジェクトを指しているように見える場合があります。その場合、Kmemleakはそのオブジェクトを「到達可能」と判定し、実際のメモリリークを見逃してしまう可能性があります。したがって、出力結果が空であるからといって、調査対象のコードに問題がないという証拠にはなりません。

さらに、対象となる割り当ての範囲も考慮する必要があります。直接ページ割り当てや ioremap カーネルのドキュメントによると、これらは追跡対象外となっています。これらの領域でメモリ使用量の増加が疑われる場合、目立たないkmemleakレポートから、その原因について「問題なし」と結論づけることはできません。そのためには、別のアプローチによる調査が必要となります。

仝 アクセシビリティ したがって、これは技術的なヒューリスティックであり、プログラムの完全な意味論的解析ではない。検出された参照が適切に使用されているか、あるいは見落とされた参照が実際に欠落しているかについて、確実な答えを与えるものではない。1件の検出結果は1つの検査項目に相当し、検出結果がない場合は、そのスキャン結果の示唆する範囲が限定されるに過ぎない。

評価を行うにあたっては、制御された条件下でその疑わしい現象を再現し、その後、関連するコードパスを確認することが有効です。特に、そのオブジェクトの所有者が誰であるか、またいつ解放されるべきかを明確にする必要があります。この調査を行って初めて、発見された現象に対する妥当な説明が得られるのです。

テスト環境と前提条件を確認する

Linux 6.6 のバージョン管理されたドキュメントが、ここでの技術的な出発点となります。ただし、お使いのシステムで kmemleak が実際に利用可能かどうかは、バージョン番号だけでなく、使用しているカーネルのビルドとその設定にも依存します。 したがって、実際にインストールされているディストリビューションのカーネルを確認し、後の評価のためにそのビルドと設定を記録しておいてください。

前提条件として、カーネルオプションがコンパイル済みである必要があります CONFIG_DEBUG_KMEMLEAK. これとは別に、 実行時の有効化: カーネルは CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF 設定すると、ブートパラメータ kmemleak=on 必要となる可能性があります。承認済みのテスト構成については、起動プロセスへの変更を明確に計画してください。

また、診断インターフェースにアクセスするには、 debugfs 利用可能であり、適切に統合されている必要があります。カーネルの設定、有効化、ファイルシステムへのアクセスは、それぞれ異なるチェックポイントです。インターフェースが欠けているという事実だけでは、その原因がどれであるかは特定できません。アクセスには特権が必要な場合があります。

可能な限り、隔離されたVMまたは専用のテストシステムを使用し、変更については事前に承認を得てください。Kmemleakは、メモリの割り当てや解放に余分な負荷をもたらします。その影響は、環境や負荷によって異なります。適切な測定を行わない限り、これによるパフォーマンスの低下について一概に述べることはできません。

カーネルに加え、調査対象のモジュール、予定されている処理の流れ、および出力のタイミングについても記録してください。診断レポートには、内部アドレスやその他の機密情報が含まれている場合があります。アクセス制限を設けて安全に保管し、第三者に開示する前に、エラー分析に実際に必要な情報がどれかを確認してください。

インターフェースと診断コマンド

公開済みのテストシステム上で、以下のファイルへの読み取りアクセスから開始してください。 /sys/kernel/debug/kmemleak. このファイルには、現在報告されている疑わしいケースが表示されます。このファイルへのアクセスには特権が必要な場合があります。出力が空の場合、それは単に表示されている診断状態を示しているだけであり、カーネルにメモリリークがないことを証明するものではありません。

十分な読み取り権限を持つシェルで、以下のコマンドを実行してください。このコマンドは診断状態を変更せず、次の手順に進む前に初期の診断結果を保存しておくのにも適しています。

cat /sys/kernel/debug/kmemleak

ファイルが見つからない場合、3つの原因が考えられます。カーネルが CONFIG_DEBUG_KMEMLEAK ビルドされたが、kmemleak が実行時に有効になっていないか、debugfs が想定された場所にマウントされていない。ファイルが存在しないという事実だけでは、どちらが原因かは特定できない。したがって、ビルド設定、ブート設定、およびマウント設定を個別に確認すること。

この表では、意図的に「読む」と「 書き込みアクセス権: スキャンを実行したり、表示されているリストを整理したりすると、診断状態が変化します。また、必要に応じて debugfs をマウントすることも、システムに影響を与えます。このような操作は、承認を得て、必要な権限がある場合にのみ実行してください。書き込みコマンドのリダイレクトにも、十分な権限が必要です。

疑わしい症例を再現性を持って絞り込む

まず、インターフェースの出力全体を、時刻、カーネルのビルド情報、およびテスト構成とともに保存しておいてください。既存のメッセージは 初期所見 また、これらを安易に以下のテストの結果として解釈してはなりません。出力結果には内部アドレスやその他の診断情報が含まれている可能性があるため、安全に保管してください。

公開済みのテストシステム上では、以下のシェルコマンドを使用して、現在表示されているメッセージを「疑わしいリスト」から除外することができます。このシェルコマンドを実行するには、インターフェースへの書き込み権限が必要です。このコマンドはメモリブロックを解放するものではなく、根本的な原因を解決するものでもありません。事前にバックアップを取らないと、重要な情報が失われる可能性があります。

echo clear > /sys/kernel/debug/kmemleak

その後、調査対象のモジュールの初期化や、管理されたクリーンアップなど、可能な限り範囲を限定し、記録を残した手順を開始してください。 どの手順が実行され、いつ完了したかを記録してください。そうすることで、後で何かが見つかった場合でも、単に時間的に近接しているという理由だけで因果関係が証明されることなく、その事象を手順とより具体的に照合することが可能になります。

タイムアウト後、適切な権限を持つシェルでスキャンを実行し、その後、インターフェースを再度読み込んでください。どちらのコマンドも、kmemleak が有効であり、debugfs インターフェースが利用可能であることが前提となります。

echo scan > /sys/kernel/debug/kmemleak
cat /sys/kernel/debug/kmemleak

手順を慎重に繰り返して、十分な時間を確保してください。スキャンは必ずしも即座に再現可能な結果を返すとは限りません。回帰テストを行う際は、カーネルの設定と負荷を可能な限り同じ状態に保った上で、コード変更の前後で同じテストを比較し、残っている差異を記録してください。 新たな疑念は仮説を裏付けるものですが、オブジェクトのライフサイクルを検証することに代わるものではありません。

モジュールテストと所見の評価

モジュールテストでは、例えば初期化パスを実行した後、所定のクリーンアップパスを実行させることができます。 その後、新しいエントリが現れた場合は、まずオブジェクトのサイズ、経過時間、プロセスコンテキスト、および関連するテスト手順を記録してください。これらの情報は、所見を特定するのに役立ちますが、それだけでは、そのオブジェクトが実際に解放されるべきだったかどうかは判断できません。

仝 割り当てのスタックトレース メモリの割り当てが要求された箇所へと導きます。そこから、コードを追跡して、誰がそのオブジェクトを引き継ぎ、どのパスで解放されるべきかを確認します。トレースには、解放が行われなかった箇所が含まれている必要はありません。割り当てと解放の漏れは、異なる関数内で発生している可能性があるからです。

また、以下の点も考慮してください。 割り当て順序: このドキュメントでは、出力結果をこの順序で説明しています。以前の孤立したオブジェクトが、さらなるメッセージを引き起こす可能性があります。したがって、複数のエントリが同じオブジェクト群やエラーパスに属しているかどうかを確認してから、それらを独立した不具合としてカウントするようにしてください。

オプションの機能テストについては、最新のカーネルドキュメントでこのモジュールについて説明されています kmemleak-test、これは意図的にメモリリークを発生させるものです。隔離されたテスト環境でのみ使用し、事前にそのカーネルで利用可能であり、適切に設定されているかを確認してください。動的に更新される最新のドキュメントであっても、古いカーネルやディストリビューション固有のカーネルすべてで利用可能であることを保証するものではありません。

この診断モジュールにおいても、最初のスキャンで即座にメッセージが表示されたり、一致が検出されたりすることは保証されません。テストの実施時刻とスキャン順序を記録し、手順に従って検査を繰り返してください。出力結果が最初は空のままの場合、診断環境が正常に動作しているか、あるいは故障しているかという結論を安易に下すのではなく、前提条件と手順を確認してください。

エラーメッセージを非表示にするのではなく、原因を確認する

疑わしいケースでは、報告されたオブジェクトのライフサイクルから調査を始めましょう。そのオブジェクトはどの関数によって予約され、その後誰が責任を引き継ぎ、いつ解放される予定なのか？ 割り当てのスタックトレースを追跡することで、予約の発生源を特定できます。エラーがその箇所にあるのか、それともそれ以降の箇所にあるのかは、コードパスを確認して初めて判断できます。

特に以下の点を確認してください。 所有関係 関数やモジュール間の引き渡しにおいて。参照が渡される場合、どちら側がその参照を保持し、どちら側が解放を行うのかを明確にする必要があります。また、初期化が部分的にしか完了しなかった場合など、通常の処理パスと、中断パスやエラーパスを比較検討してください。

kmemleak が認識できない有効な参照が存在する場合でも、エラーが発生することがあります。そのため、このエラーを抑制する前に、ポインタがどこに、どのような形式で格納されているかを確認してください。そのオブジェクトが想定された存続期間中、なぜアクセス可能な状態が維持されるのか、そして最終的にどのような方法で解放されるのかを文書化してください。

検証済みの特殊なケースについては、開発者向けに 注釈 利用可能： kmemleak_not_leak 既知のオブジェクトを「リークではない」としてマークしますが、引き続き参照のスキャンは行います。 kmemleak_ignore そのオブジェクトを、メッセージおよびスキャンの両方から除外します。これにより、そのオブジェクトに含まれる参照が分析対象から漏れる可能性があります。

実際に使用しているカーネルにおけるAPIの可用性と意味論を確認してください。最新のAPIドキュメントは、必ずしもすべての古いビルドに対して保証されているわけではありません。アノテーションは、承認の欠如や誤った所有権の変更を解決するものではありません。 したがって、問題となる出力を消すためだけに、これを単独で使用しないでください。

トラブルシューティングと安全な運用

ファイルが見つかりません /sys/kernel/debug/kmemleak, まずは実際に起動したカーネルビルドとその設定を確認してください。 CONFIG_DEBUG_KMEMLEAK 必ず存在している必要があります。ディストリビューションのバージョン番号だけでは不十分です。後の比較が同じ基準で行われるよう、ビルドと構成を記録しておいてください。

それとは別に、以下の項目を確認してください。 実行時の有効化 および debugfs の組み込み。 CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF ブートパラメータは kmemleak=on 必要となる場合があります。欠落しているファイルだけでは、これらの考えられる原因を区別することはできません。ブートプロセスの変更やdebugfsのマウントは、承認済みのテスト構成で行う必要があります。

テスト後の出力が空のままの場合は、対象のプロセスが実際に実行されたかどうか、およびプロセスとスキャンとの間に十分な時間的間隔があったかどうかを確認してください。 文書化された条件下でテストを繰り返し、保存済みの初期結果と比較してください。ただし、その場合でも、空のレポートには限界があります。kmemleakがすべての割り当てや関連する参照を検出するわけではないからです。

診断状態の変更が行われる前に、既存の所見を保存しておいてください。出力には内部アドレスやその他の機密情報が含まれる可能性があるため、ご利用の環境におけるアクセスおよび公開ルールに従って取り扱ってください。 状態を変更する操作は、可能な限り隔離された共有テストシステム上で実行し、診断にかかる追加の工数を考慮に入れるとともに、そのために根拠のないパーセンテージを仮定しないようにしてください。

メモリ使用量が多い、あるいは メモリプレッシャー これは独立した運用上の問題であり、それ自体ではカーネルリークの証拠とはならない。待ち時間やメモリ不足を評価するにあたっては、以下の記事が参考になる。 Linuxカーネルにおけるメモリプレッシャー. こうした稼働状況の観察結果を、的を絞ったコードおよび所見の検証と組み合わせ、RAM曲線から直接原因を推測するのではなく、分析を行うこと。

適切な診断ツールを選ぶ

予想されるものに基づいてツールを選択してください エラーカテゴリ、単にメモリ使用量の増加という一般的な症状だけに基づいて判断するわけではありません。kmemleakは、孤立している可能性のある、カーネルがサポートするオブジェクトを探します。ユーザープロセスの不正なアクセスやメモリの問題については、別の監視手法を用いるのが適切です。これらのツールは、それぞれ異なる問題を解決するためのものです。

カーネル参照の喪失が疑われる場合は、まずkmemleakが考えられます。一方、エラーパターンがオブジェクトの範囲外へのアクセスや、すでに解放されたメモリへのアクセスを示している場合は、この種の調査にはKASANが適しています。 KFENCEも特定のメモリエラーを追跡しますが、異なる計測手法を採用しています。利用可能性や適性は、具体的なカーネルやテスト環境によって異なります。

ユーザー空間のプロセスに疑いがある場合は、Valgrind Memcheckなどの専用ツールを使用して、そのプロセスのメモリを調査してください。 カーネルオブジェクトに関するkmemleakレポートは、アプリケーションのヒープ分析に代わるものではありません。逆に、ユーザープロセスからの指摘があっても、それが必ずしもカーネルモジュールがメモリを漏らしていることを示すわけではありません。

今後の作業のために、いずれかを選択してください 再現可能な試験 そして、カーネルのビルド、設定、および実行手順を記録する。コード内で報告されたオブジェクトのライフサイクルを調査し、特定された原因を修正した上で、可能な限り同様の条件下で同じ手順を繰り返す。 調査結果を再度比較してください。エラーが発生しなくなったという事実だけでは、完全に不具合が解消されたとは言い切れません。