Masami HIRAMATSU
hiram****@sdl*****
2002年 7月 2日 (火) 15:46:21 JST
日立の平松です。 lkst-1.2リリース直後ですが、現状新たに見つかった問題点と改善策 (修正中のものも含まれます)を明らかにしておきたいと思います。 ＃すこし長めになってしまいました。 (1)lkst_evhandler_register が 与えたIDのイベントハンドラを 上書き登録してしまう。このため、デフォルトのイベントハンドラ が登録されているIDに上書きしてしまうことができる。 改善策）lkst_evhandler_registerの仕様変更、lkst_evhandler_unregister lkst_evhandler_get_idの2つのAPIの追加を行う。 registerに関しては、・システム予約IDへの変更不可、・IDの自動割当 ・名前の重複禁止、の3点を中心に行います。 また、これまでNULLを登録することでevhandlerを削除してきましたが 専用のunregister関数を使うように変更します。 また、ハンドラに付けた名前からIDを引いてこれるようにget_idを 追加します。 この変更についてはこちらで修正済ですが、APIの変更に関して 何か問題等ありますでしょうか。 (2)バッファオーバーライト判定にバグの可能性。 (3)バッファ解放時に(ロックを取っていないので)アクセスバイオレーションを 起こす可能性がある。 改善案）LKSTでは、CPU毎に書き込みバッファを持っているので、イベント取得 時にロックを極力省けるのですが、バッファリードやバッファの操作に 関しては担当していないCPUからの操作が入ってしまうことになり、上 記のような問題が発生します。そこで、これらのバッファ操作に関しては、 操作を行うプロセスを対象バッファを持つCPU上にmigrateして実行し、 ロックをとらなくてもすむようにしたいと考えています。 具体的には以下のように考えています。 (2) ・リードプロセス(ほとんどの場合lkstlogd)は、set_rmodによって対象CPUに migrateし リードコマンドを発行する。 ・読み出しと書き込みが同一CPUのカーネルタスク上で行われるため、オーバー リード・ オーバーライト判定をしなくてもよい。 (3) ・ カレントバッファでないか調べ、defunctフラグ(atomic)を立て（これは解放 プロセ ス中のバッファに、シフトインしないようにするためである）、再びカレント バッファ でないか調べる。2度目の確認で失敗したらdefunctフラグを倒してエラーで戻る。 （このプロセスは、バッファの解放、リストやリングからはずすときにも使われる） ・その後 バッファ解放プロセスは、cpus_allowedフラグを使ってバッファを使 うCPUへ スケジュールされるのを待ち、解放する。 ・シフトプロセスはdefunctフラグがたっていなければシフトする。 (4)デーモンにSIGTERMを送ったときにバッファを二度読んでしまう。 改善策）オーバーリードの判定とsignalの判定がうまく働かないために生じる現 象ですが、 上記のようにオーバーリード判定が不要になれば自然に治るのではないかと 思われます。 また、もう一つの案として、SIGTERMを送ると同時にバッファシフトさ せると いう方法が考えられています。 以上です。 ご意見いただけるとありがたいです。 -- 平松 雅巳(Masami HIRAMATSU) (株)日立製作所 システム開発研究所 第３部 304ユニット E-mail: hiram****@sdl***** (外線)044-959-0258 (内線)8-69-3346
