On Fri, 2014-01-24 at 17:16 +0530, Tejas Vaykole wrote:
> On 1/23/2014 1:10 AM, Nicholas A. Bellinger wrote:
> > on-immediate
> > data
> Hi Nicholas,
>
> Thanks for the explanation.
>
> However, I went back and double checked, what we are doing is little
> different. We are sending
> ImmediateData with is larger than FBL, which is < EDTL with F=0. RFC
> section 10.4.7.2
> points that this should return "Unexpected unsolicited data". Please
> note that the
> ImmediateData=Yes in this case.
>
> RFC Section 10.4.7.2
> +--------------------------+----------+---------------------------+
> | Unexpected unsolicited |Aborted | ASC = 0x0c ASCQ = 0x0c |
> | data |Command-0B| Write Error |
> +--------------------------+----------+---------------------------+
>
I don't think that 'Unexpected unsolicited data' is intended to be used
for this case, and AFAICT there is nothing in the RFC that says this
must be returned for the specific scenario where ImmediateData payload
exceeds FirstBurstLength.
My interpretation is that 'Unexpected unsolicited data' is intended to
be used when any Unsolicited Data-Out PDU is received, but
InitialR2T=yes has been negotiated. Given that it says 'unsolicited'
and not 'unsolicited data-out', it could also be interpreted that
receiving an immediate data payload when ImmediateData=No should also
generate this exception.
Or to put it simply, it means "you sent me unsolicited data out, when
our session negotiated to only use solicited data".
(Note current code REJECTs immediate data payload with ImmediateData=No)
> It looks like it is failing in this part of code.
>
> Linux/drivers/target/iscsi/iscsi_target.c:iscsit_setup_scsi_cmd()
>
> if (payload_length > conn->sess->sess_ops->FirstBurstLength) {
> 908 pr_err("DataSegmentLength: %u is greater than"
> 909 " FirstBurstLength: %u, protocol error.\n",
> 910 payload_length, conn->sess->sess_ops->FirstBurstLength);
> 911 return iscsit_add_reject_cmd(cmd,
> 912 ISCSI_REASON_BOOKMARK_INVALID, buf);
> 913 }
>
>
>From 3.2.4.2. Data Transfer Overview
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.
Notice it doesn't describe which type of error, or that these two cases
are considered the same error. ;)
In current code the first error is interpreted as CHECK_CONDITION +
'Unexpected unsolicited data' ASC/ASCQ, and latter error as mentioned
above for ImmediateData is a REJECT + Invalid field in PDU.
> The other case you are mentioning where FBL < EDTL and non-immediate
> data (data-out) with F=1. This case should
> return "Incorrect amount of data". I am quoting this from RFC section
> 10.4.7.2
>
> RFC Section 10.4.7.2
> +--------------------------+----------+---------------------------+
> | Incorrect amount of data |Aborted | ASC = 0x0c ASCQ = 0x0d |
> | |Command-0B| Write Error |
> +--------------------------+----------+---------------------------+
>
Also from 10.4.7.2:
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.
Here's what the code for this case looks like in
iscsi_target_erl0.c:iscsit_dataout_check_unsolicited_sequence():
if ((first_burst_len != cmd->se_cmd.data_length) &&
(first_burst_len != conn->sess->sess_ops->FirstBurstLength)) {
pr_err("Unsolicited non-immediate data"
" received %u does not equal FirstBurstLength: %u, and"
" does not equal ExpXferLen %u.\n", first_burst_len,
conn->sess->sess_ops->FirstBurstLength,
cmd->se_cmd.data_length);
transport_send_check_condition_and_sense(&cmd->se_cmd,
TCM_INCORRECT_AMOUNT_OF_DATA, 0);
return DATAOUT_CANNOT_RECOVER;
}
AFAICT this is doing the correct thing, but note there is still another
use of TCM_INCORRECT_AMOUNT_OF_DATA proceeding this one within
iscsit_dataout_check_unsolicited_sequence() that should probably be
changed to something else.
> Please let me know if my understanding is correct.
>
So I'm still not convinced the standard mandates these the use of
'Unexpected unsolicited data' for your particular test case. I could be
swayed however, if Julian Satran has a specific opinion on this..
--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
