On Tue, Jan 8, 2013 at 7:48 PM, Nicholas A. Bellinger <nab@xxxxxxxxxxxxxxx> wrote: > Digging into this a bit more, I'm starting to think the root problem is > that the CMD_T_ACTIVE bit in se_cmd->transport_state is getting cleared > by transport_cmd_check_stop() during transport_generic_new_cmd() for > pending WRITEs before the cmd->se_tfo->write_pending() callback occurs, > but is not getting reset until way too late in target_complete_cmd(). > > This bit used to be set each time in transport_add_cmd_to_queue() when a > se_cmd was added to the legacy transport_processing_thread() logic > (including for iSCSI WRITEs), but this has since been removed starting > from v3.6 code. (Here is the v3.5.x reference for good measure) > > http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=blob;f=drivers/target/target_core_transport.c;h=0981707216b7f937db1b7a6931b9df113048ecef;hb=refs/heads/linux-3.5.y#l600 > > So here is a quick patch to explicitly re-set CMD_T_ACTIVE within > target_execute_cmd(), which is the function that iscsi-target now calls > in >= v3.6.x to submit individual WRITEs once the full data payload has > been received. > > diff --git a/drivers/target/target_core_transport.c b/drivers/target/target_core_transport.c > index 978762d..1689c8b 100644 > --- a/drivers/target/target_core_transport.c > +++ b/drivers/target/target_core_transport.c > @@ -1687,6 +1687,7 @@ void target_execute_cmd(struct se_cmd *cmd) > return; > } > > + cmd->transport_state |= CMD_T_ACTIVE; > cmd->t_state = TRANSPORT_PROCESSING; > spin_unlock_irq(&cmd->t_state_lock); Yes, I sent the same patch last week. Not sure if it fixes the crash in this mail thread, but see http://permalink.gmane.org/gmane.linux.scsi/79495 (or your backlog of target-devel mail) for a detailed explanation of another reason why it's needed. -- 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
