On Tue, 2013-05-14 at 12:29 -0400, Jörn Engel wrote: > On Mon, 13 May 2013 20:08:44 -0700, Nicholas A. Bellinger wrote: > > On Mon, 2013-05-13 at 18:00 -0400, Jörn Engel wrote: > > > > > > I agree that the overhead doesn't matter. The msleep(100) spells this > > > out rather explicitly. What does matter is that a) the patch retains > > > old behaviour with much simpler code and b) it fixes a race that kills > > > the machine. I can live without a, but very much want to keep b. ;) > > > > Fucking around with ->sess_cmd_lock during each loop of ->sess_cmd_list > > in target_wait_for_sess_cmds is not simpler code.. > > I could argue that fucking around with ->sess_cmd_lock during each > loop is simpler than the communication through cmd_wait_set and > cmd_wait_comp. But simplicity is ultimately subjective and we can > argue all day. > What I don't like is the endless loop in target_wait_for_sess_cmds() that acquires and releases ->sess_cmd_lock for every command, with a hard-coded msleep thrown in. > > > drivers/infiniband/ulp/srpt/ib_srpt.c | 2 +- > drivers/scsi/qla2xxx/tcm_qla2xxx.c | 2 +- > drivers/target/target_core_transport.c | 64 +++++++++----------------------- > include/target/target_core_base.h | 2 - > include/target/target_core_fabric.h | 2 +- > 5 files changed, 20 insertions(+), 52 deletions(-) > > But diffstat is reasonably objective. Do you really want me to come > up with an alternative patch that adds code instead of removing it? > What I want is the part of Roland's commit reverted that introduced the regression, that started you down this particular path of adding unnecessary locking to target_wait_for_sess_cmds(). And if your using diffstat as a guide, after re-adding the handful of parts for ->sess_wait_list from commit 1c7b13fe6 plus removing the dead code in target_wait_for_sess_cmds(), the number of changed lines will still be a net minus. --nab -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
