下川です. At Wed, 31 Oct 2007 23:54:21 +0900, Mitsuru IWASAKI wrote: > > レポートした時点に近い10/26 00:00:00 GMT時点のcurrentにあてて > > 試してみました。結果はマルチになる前にpanicしてしまいました。 > > 申し訳ないです、ちょっと急ぎすぎましたね。今度はどうでしょう? > > http://people.freebsd.org/~iwasaki/ciss/ciss_periodic_thread-20071031.patch
codeを斜め読みしだけなので, 間違ってるかもしれませんが, 気になった点をいくつか指摘させてください. 1. lock の範囲 witnessを黙らせるために, ciss_synch_request() を call するとき のみ lock を持ってますが, これだけで十分でしょうか? ciss_get_request() も ciss_dequeue_free() あたりで, tailq を いじっているので, lock を持ってないと, tailq を壊す可能性が あると思います. ちなみに callout version では, callout_init_mtx() しているので, lock は持っています. ふつうこの手の thread を実装する場合には, ciss_periodic_thread() の先頭で mutex を取得します. そして, 仕事が終ったら, tsleep() しないで msleep() して lock を解放しておやすみします. 2. kproc_exit と detach これは, ちょっとややこしい話で, kldunload と, hot unplug とかしないと表面化しない話ですが, ciss_detach() するときに, kproc が exit するのをちゃんと 見届けてあげないと, page fault 等がおこります. periodic_thread は, 大抵 sleep しているわけで, その間に kldunload とかされてると, driver の code が kernel space からいなくなってしまい, 起きたときには, ここはどこ状態になります. なので, detach するきには, thread を起して, exit するまで 待たないといけません. ciss_periodic_thread()にも, ciss_kill_notify_thread() 相当 のものが必要です. 3. kproc 必要? 私の印象ですが, nop送るだけなら, わざわざ, kproc 作る必要が あるかなと思います. 同期 request を使うから sleep しなくて はいけないのであって, 普通に非同期 request して, callback で, struct ciss_reqest を解放する位で良いような 気がします. /\ Hidetoshi Shimokawa \/ [メールアドレス保護]
