Hi Tejas,
On Wed, 2014-01-22 at 12:50 +0530, Tejas Vaykole wrote:
> Hi,
>
> I am testing SCSI response to Excess Immediate Data on LIO Target. Is my
> understanding correct ?
> I am referring to RFC 3720 Section 3.2.4.2
>
> I am setting FirstBusrtLength=512, ImmediateData=Yes, InitialR2T=Yes
> I am sending unsolicited data of 1024 which is greater than
> FirstBusrtLength(512).
> I am expecting a check condition for Unexpected unsolicited data (RFC
> Section 10.4.7.2. Sense Data )
> However, LIO is sending a reject PDU (Reason 0x09 ).
>
> Quote from the RFC 3720 Section 3.2.4.2. Data Transfer Overview
> ----- Snip -----
> It is considered an error for an initiator to send unsolicited data
> PDUs to a target that operates in R2T mode (only solicited data are
> allowed). It is also an error for an initiator to send more
> unsolicited data, whether immediate or as separate PDUs, than
> FirstBurstLength.
So, looking at when unsolicited data-out exceeds the session negotiated
FirstBurstLength, the code appears to be doing the correct thing in
iscsi_target_erl0.c:iscsit_dataout_check_unsolicited_sequence():
if (first_burst_len > conn->sess->sess_ops->FirstBurstLength) {
pr_err("Total %u bytes exceeds FirstBurstLength: %u"
" for this Unsolicited DataOut Burst.\n",
first_burst_len, conn->sess->sess_ops->FirstBurstLength);
transport_send_check_condition_and_sense(&cmd->se_cmd,
TCM_INCORRECT_AMOUNT_OF_DATA, 0);
return DATAOUT_CANNOT_RECOVER;
}
Also, this case will generate CHECK_CONDITION with
TCM_INCORRECT_AMOUNT_OF_DATA, and not TCM_UNEXPECTED_UNSOLICITED_DATA as
mentioned above, following what is described in Section 10.4.7.2. Sense
Data:
The target reports the "Incorrect amount of data" condition if
during data output the total data length to output is greater than
FirstBurstLength and the initiator sent unsolicited non-immediate
data but the total amount of unsolicited data is different than
FirstBurstLength.
However, I think your test case is hitting a different check earlier in
the dataout callchain, namely iscsi_target.c:iscsit_check_dataout_hdr()
code here:
if ((be32_to_cpu(hdr->offset) + payload_length) > cmd->se_cmd.data_length) {
pr_err("DataOut Offset: %u, Length %u greater than"
" iSCSI Command EDTL %u, protocol error.\n",
hdr->offset, payload_length, cmd->se_cmd.data_length);
return iscsit_reject_cmd(cmd, ISCSI_REASON_BOOKMARK_INVALID, buf);
}
which is following Section 10.17.1. Reject Reason, (Note 2):
Note 2: A target should use this reason code for all invalid values
of PDU fields that are meant to describe a task, a response, or a
data transfer. Some examples are invalid TTT/ITT, buffer offset, LUN
qualifying a TTT, and an invalid sequence number in a SNACK.
So, AFAICT this is doing the right thing for the case when the
unsolicited data exceeds not only FirstBurstLength, but the EDSL as
well.. (dmesg output would be helpful to verify)
I'm guessing that using a larger EDSL would cause the
TCM_INCORRECT_AMOUNT_OF_DATA case to trigger instead of the earlier
ISCSI_REASON_BOOKMARK_INVALID.
--nab
P.S: I'd recommend using >= v3.10 code and above instead of v3.9 for
testing. There where quite a few changes to iscsi-target code added to
support iser-target in v3.10, and I'd really like to get more test
coverage on those kernels.
--
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
