Dne 9.1.2013 5:19, Nicholas A. Bellinger napsal(a): > On Tue, 2013-01-08 at 19:56 -0800, Roland Dreier wrote: >> 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. > <nod>, sorry still catching up on the backlog + busy on WIP v3.9 > iSER-target bits. ;) > >> 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. > I'm quite certain at this point that Martin's active I/O shutdown OOPsen > here is due to the same >= v3.6 regression bug of CMD_T_ACTIVE not being > re-set during pending WRITEs I/O submission. > > So that said, I'll finish catching up tomorrow and end up applying your > patch as the proper fix for mainline. > > Thanks Roland! > > --nab > I applied the patch to v3.7.1 and got no oopses after two hours of testing. I'll give it few more hours to be sure but the regression bug seems to be fixed. Thanks Roland and Nick Martin -- 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
