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; > > Is there an issue with target not able to retrieve the correct ITT ? I > did not get time to look into it. > It looks like some combination of re-using the same ITT before the original is being acknowledged by StatSN.. I assume if you are using normal incrementing ITTs, you'll not trigger the problem. It would be worthwhile to verify that bit. > > > > > Please include a wireshark capture, along with iscsi_target_mod pr_debug > > output enabled. > > Attaching the pcap. I am basically opening 2 connections.First being the > leading connection.And I am performing a READ10 and WRITE10 operation on > both the connections. > Thanks, --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
