TOMOYO Linux 1.7.0 に存在していた、環境変数のアクセス許可のチェック時に if 節で環境変数を使えない（ allow_env PATH if exec.envp["PATH"]="/" のような指定ができない）という不具合を修正する際に、メモリリークするバグが新たに埋め込まれていたことが判明しました。環境変数のアクセス許可のチェック機能が有効な場合、１回のプログラム実行要求につき４ＫＢのメモリがリークしていくため、そのうちメモリ不足に陥ってしまいます。
http://sourceforge.jp/projects/tomoyo/lists/archive/users/2009-December/000718.html
カーネル 2.6.31 にメモリリーク検出機能（ CONFIG_DEBUG_KMEMLEAK ）がマージされたことに伴い、 TOMOYO 1.7.0 では TOMOYO 独自のメモリ使用量カウンタを廃止したのですが、実は CONFIG_DEBUG_KMEMLEAK の扱いに苦労しています。
というのも、メモリリーク検出機構が有効化されるまでに発生するメモリ割り当て処理を記憶しておくためのトレース用バッファが不足して自動的に無効化されてしまう（そのため、本人は有効にしているつもりでも実際には機能していないので検出できない）とか、 SLAB アロケータを選択した状態で特定のデバッグオプションと組み合わせて使うと（無限再帰呼び出しにより）スタックオーバーフローが発生して起動不可能に陥るとかしているためです。デバッグオプションをなるべく有効にしながらメモリリークの検出も行うというのは試行錯誤が必要でした。
一昨日リリースされた 2.6.33-rc1 では有効な状態で起動できるようになり、 TOMOYO の処理の中でメモリリークが起こっているらしいことが判明しました。しかし、スタックトレースの出力が示している関数の中の何処が間違っているのか悩みました。スタックトレースはアクセス制御が有効でも無効でも呼ばれる関数の中で割り当てられた４ＫＢのメモリが解放されていないと報告しており、４ＫＢのメモリを割り当てている箇所は１つしかありません。しかし、デバッグ文を挿入して割り当てと解放の回数をカウントしてみても問題点を見つけられなかったため、誤検出ではないかと思いました。ところが、テストプログラムを作成しても再現できないため、他の TOMOYO の関数ではないかと疑い始めました。そして、アクセス制御を有効にしないとメモリリークが発生しないことを突き止め、環境変数のチェックを行う関数で発生していることが判明したのが昨夜のことです。環境変数のチェックを行う関数に対して明示的に noinline 指定をしていなかったために、コンパイラがアクセス制御が有効でも無効でも呼ばれる関数の中に inline 展開してしまったことにより、アクセス制御が有効でも無効でも呼ばれる関数の側ではなく環境変数のチェックを行う関数の側に問題があることに気づくのに手間取ってしまいました。はぅ〜、難しいなぁ。
2.6.33-rc1 への対応を追加した tar ball を TOMOYO 1.7.1p1 としてアップロードしましたのでご利用ください。
| 問題のあるファイル | ccs-patch-1.7.1-20091111.tar.gz |
| 修正されたファイル | ccs-patch-1.7.1-20091220.tar.gz ( MD5: 8888488e0e704c4302480a0af476426c ) |
バイナリパッケージは現在再作成中です。