おっしゃる通りである。追加されていて、セマフォじゃなくてミューテックスで保護してるので、排他自体はしてるだが、ミューテックスって誰かとバッティングしないかぎりatomic_xchg();smp_mb();の2行で抜けてくるので、プリエンプションはdisableされてないっぽげ。ワーストケースでは、i_size_write中にプリエンプションされてi_size_readがえらい待たされるケースがありそうな気がするでゴワスよ。前回の指摘の1は、やっぱり疑わしい。2と3は脳みそが腐っていたっぽげ。17:53i_semをロックする際、preempt_disableはしてないです。勘違いしてました、ぺこり。i_size_write()のwrite_seqcount_begin()直後に割り込みが発生し、プリエンプションしたら他のスレッドにて実行中のi_size_read()はread_seqcount_retry()しまくるでしょうね。&gt;なので、やっぱりワーストケースでは、i_size_write中にプリエンプションされてi_size_readがえらい待たされるケースがありそうな気がするでゴワスよ。運用的に考えるとCONFIG_SMP&CONFIG_PREEMPTは”今まで”はあまり考えられないケースです。MPは通常サーバなのでスループット重視でCONFIG_PREEMPT_NONEに設定されます。すると、このコードを書いた人はそういった想定をしていない可能性はあります。inode-&gt;i_sizeの扱いに関して、個人的にセマフォやmutexを使う必要があったのか疑問を持っています。排他区間が極めて小さいことを考えるとスピンロックを使うべきではないかと。スリープさせるよりビジーウェイトで回した方が排他コストが低いように思います。18:09ああ、なるほどね。そんな運用しませんから。それは納得できる意見ですね。スピンロックの件はすいません。オイラI/O系あんまり強くないんで判断できません。「Amazonライブリンク」は提供を終了しました。