On Thu, 2014-06-19 at 23:43 -0700, Nicholas A. Bellinger wrote:
> On Fri, 2014-06-20 at 11:30 +0530, Santosh Kulkarni wrote:
> > Hi Nab,
> >
> > On Friday 20 June 2014 01:47 AM, Nicholas A. Bellinger wrote:
> > > On Thu, 2014-06-19 at 14:16 +0530, Santosh Kulkarni wrote:
> > >> Hi Nab,
> > >>
> > >> On Thursday 19 June 2014 01:32 AM, Nicholas A. Bellinger wrote:
> > >>> Hi Santosh,
> > >>>
> > >>> On Wed, 2014-06-18 at 15:34 +0530, Santosh Kulkarni wrote:
> > >>>> Hi Nab,
> > >>>>
> > >>>> Facing Kernel OOP when i am issuing Writes across Multiple connections
> > >>>> in a single session.
> > >>>> The crash happens immediately when the DataOut PDU is sent on the second
> > >>>> connection.
> > >>>>
> > >>> To confirm, this occurs when the initiator sends a ISCSI_OP_SCSI_CMD
> > >>> with ITT=X setting it's allegiance to one connection, and then
> > >>> (illegally) sends a ISCSI_OP_SCSI_DATA_OUT with ITT=X on another
> > >>> connection, right..?
> > >> There was a slight mistake in the way i formed my sentence earlier.
> > >> The WRITE10 request and DataOut PDUs are being issued on the "same
> > >> connection" within a session.
> > >> The Crash happens only when this is issued on multiple connections.ITT
> > >> remains same across all connections
> > >> If i carry out WRITE only on single connections the target is behaving fine.
> > >> And the behavior is not persistent.It happens intermittently.Here is a
> > >> new crash dump
> > >>
> > > Mmmmm, I need the pr_debug output to be enabled in order to make further
> > > sense of what's going on here.
> > >
> > > Please enable CONFIG_DYNAMIC_DEBUG=y, mount debugfs at /debug and do:
> > >
> > > 'echo iscsi_target_mod +p' > /debug/dynamic_debug/cpmtrp;
> >
> >
> > Thanks for the quick response.
> >
> > The output was with dynamic debug mode ON.
> > However i double checked with the above procedure. And i see the same
> > debug logs.
>
> When dynamic debug is enabled, the pr_debug() messages appear in dmesg
> output, and not in the normal syslog / klog messages.
>
> Eg: You should see normal PDUs being processed from pr_debug() output in
> dmesg when enabled, along with the pr_err() output from the previous
> email.
>
> > The crash happens even with incremental ITT and also while using same
> > ITT throughout the session.
> >
> > Do let me know if you need anything else.
> > Adding Arshad in Cc.
>
> Can you send along the specific test off-list please..?
>
One other quick thing to try is the following patch to dump the Data-out
payload when a ITT received is not associated with a WRITE (following
the log), instead of generating a Reject for the existing ITT.
I can't quite tell from wireshark output why your test is sending
Data-out with an ITT that is associated with a READ that has not been
acknowledged by StatSN, but the following should at least leave the READ
ITT alone.
--nab
diff --git a/drivers/target/iscsi/iscsi_target.c b/drivers/target/iscsi/iscsi_target.c
index b87721a..049fe14 100644
--- a/drivers/target/iscsi/iscsi_target.c
+++ b/drivers/target/iscsi/iscsi_target.c
@@ -1308,7 +1308,7 @@ iscsit_check_dataout_hdr(struct iscsi_conn *conn, unsigned char *buf,
if (cmd->data_direction != DMA_TO_DEVICE) {
pr_err("Command ITT: 0x%08x received DataOUT for a"
" NON-WRITE command.\n", cmd->init_task_tag);
- return iscsit_reject_cmd(cmd, ISCSI_REASON_PROTOCOL_ERROR, buf);
+ return iscsit_dump_data_payload(conn, payload_length, 1);
}
se_cmd = &cmd->se_cmd;
iscsit_mod_dataout_timer(cmd);
--
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
