テストステ論

高テス協会会長が, テストステロンに関する情報をお届けします.

(writeboost report) デッドロックを避けるためにwqにI/O実行させた時の, lockdepによるfalse positiveなデッドロック判定

ストレージソフトウェアは, 通常, メモリ上で作業をしてから, 結果をストレージメディアに反映させる. DMでは, これについてdm_ioという汎用的なルーチンが提供されている. しかしこのルーチンには, (最近直ったのかも知れないが)欠陥があり, DMターゲットがこのルーチンを使って同期IOをすると, デッドロックを引き起こす場合がある. この件については過去に書いた.

device-mapperの仕組み (6) dm_ioで同期I/O. デッドロックに気をつけて! - テストステ論

この問題に対するワークアラウンドとしては, 一旦別のスレッド(wq)に実行を委譲するというものがあり, ライトブーストはこのアプローチをとっている.

ライトブーストの1.0に向けて3.10カーネルをマイクロサーバに入れて, その上でライトブーストのdmtsを実行する作業をしているのだが, git_extract_cache_quickテストで稀にlockdepがわめきたてる. しかしこれはfalse positiveだと私は考えている.

同様のアプローチをとっているものとして, dm-snapがある. 調べると, dm-snapも同様の問題を修正している.

[dm-devel] [PATCH] dm-snapshot: workaround for a lockdep warning

あらすじはこうである.

  • ミク: flush_workがlockとってるのと, md->io_lockをとるのがデッドロックを起こすと指摘しているが, これはfalse positiveである.
  • ミク: 3.11以降ではio_lockを排除しているのでこの問題は起こらないはずだが, それ以前では起こるかも知れないのでstableにバックポートする. ゼネック, あなたの環境では再現する?
  • ゼネ: 3.11で再現する.
  • ミク: おかしいな. でも実はこの処理は性能があまり関係ないので, flush_workqueueにしてしまおう. ゼネック, そうすると再現するか?
  • ゼネ: 再現しない.
  • ミク: では, flush_workqueueにすることにしよう.

たぶん, flush_workをflush_workqueueに変更してしまえば問題はなくなる. 問題は, そうしても問題はないか?だが, たぶん問題はない. (さらにいうと, Concurrent Workqueueを使うメリットもないのでPortabilityを考える上で安定しているSingle Threadにしてもいいと思う)

false positiveとはいえ, lockdepがわめきたてるのを見たら, きっとユーザはびっくりして「もうライトブーストなんか嫌だ!」「やっぱ拝承ストレージが最高なんだ!」と騒ぎ出すだろうし大変めんどくさいので, 黙らせる方針でいく. ただし, 今のところその方式は検討中ということにしておく. いずれにしろ, v1.0へのマイルストーンとする.