On Tue, 2013-11-12 at 23:03 +0000, Moussa Ba (moussaba) wrote: > Your latest patch seems to have addressed the problem, I have not been > able to reproduce it post patch and can readily reproduce it with the > mainline 3.12 kernel. I will run a longer test tonight, but this seems > to have done it. > Excellent. Ok, so in the end this was bug due to a misinterpretation of how mutex_trylock() works.. I was originally under the assumption that mutex_trylock() was returning zero upon contention when cmdsn_mutex was already held by the same process (as can happen in the iscsi_execute_cmd() exception response path), and not from a different process (as expected between normal session RX/TX process contexts).. Simply avoiding the direct ib_isert callback in lio_queue_status() for the special iscsi_execute_cmd() exception cases allows the problematic mutex_trylock() usage in iscsit_increment_maxcmdsn() to go away entirely. I'll put these into proper patch series shortly. Thanks again, --nab -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
