iscsi_data.size is used as parameter to memory
operation functions (such as malloc) which except
size_t rather than int.
Signed-off-by: Peter Lieven <pl@kamp.de>
Add support for BUSY status coide from the target and just pass this
back to the application as is (instead of converting it to _ERROR).
This allows the application to trap task->status==SCSI_STATUS_BUSY and
decide what/how to proceed.
Ordering by itt adds the special case of handling
itt == 0xffffffff. Order by CmdSN instead as described
by RFC3720.
Signed-off-by: Peter Lieven <pl@kamp.de>
Queing packets with itt = 0xffffffff (e.g. NOP-Out replies) ahead
of queue because they might have a higher CmdSN than following
packets. This again could lead to a deadlock AND its a protocol
violotion:
RFC3720 Section 3.2.2.1 second last paragraph on Page 21:
"On any connection, the iSCSI initiator MUST send the commands in
increasing order of CmdSN, except for commands that are retransmitted
due to digest error recovery and connection recovery."
Signed-off-by: Peter Lieven <pl@kamp.de>
This patch adds support for read/writev to directly read and write
from/to iovectors. Before this patch on read and write from/to socket
the operation was limited by the iovec boundaries. If there is enough
data in the buffer or enough buffer space available its now possible
to transfer the whole data in one atomic operaion.
Signed-off-by: Peter Lieven <pl@kamp.de>
This will set TCP_NODELAY on the socket connection
to the target. This is the first step to improve latency.
For systems supporting TCP_CORK we plan to add a cork
around certain PDUs e.g. DATA-Out, but this needs further
testing.
Signed-off-by: Peter Lieven <pl@kamp.de>
We first merge waitpdu and outqueue queues and then requeue
the elements. iscsi_add_to_outqueue() will sort them accordingly
so this is no problem.
Signed-off-by: Peter Lieven <pl@kamp.de>
We where modifying out_offset and out_len in iscsi_write_to_socket().
If the packet that was being sent before reconnect was a write command
the was a significant change that out_offset and out_len where already
touched. When requeing the packet after reconnect we where
sending garbage!
Signed-off-by: Peter Lieven <pl@kamp.de>
This patch adds the abilitiy to libiscsi to count the number
of consecutive outstanding NOPs.
With this ability its fairly easy to implement a keepalive
check with NOPs in your application.
Periodically (e.g. every 5 secs) create a NOP-Out with:
iscsi_nop_out_async(iscsi, NULL, NULL, 0, NULL);
At that time check the number of consecutive missing NOP-Ins
with
iscsi_get_nops_in_flight(iscsi) > N.
Where N is the number of missing NOP-Ins you will allow.
Please note that it is legitime for the Target to ignore
a NOP if the load is very high as those packet are mark
as IMMEDIATE.
Signed-off-by: Peter Lieven <pl@kamp.de>
Just like DATA_OUT we should just discard NOPs instead of requeueing them
on session reconnect.
Add new flag that to indicate this behaviour on reconnect and set it for
both data out and nops
In specific situation it might be useful to give up if a reconnect
is not successful or after a given number reconnect retries.
This patch adds the ability to change that. The default remains
the same: retry forever.
Signed-off-by: Peter Lieven <pl@kamp.de>
The preallocation logic was messing with size and offset of pdu->indata.
This was broken when we removed iscsi_data->alloc_size. Removing
entirely since reading without iovectors is deprecated.
Signed-off-by: Peter Lieven <pl@kamp.de>
A storage might sent an R2T response for a WRITE command while
we still sending out the WRITE command PDU. This is especially
the case when the command PDU carries immediata data.
Without this patch the R2T response will get lost as
the cmdpdu for the R2T cannot be found in iscsi_process_pdu()
leading to a deadlock.
Signed-off-by: Peter Lieven <pl@kamp.de>
Add comments to explain how/why we send unsolicited data.
This is a somewhat hairy area and it is easy to make mistakes here, so
extra comments on the how/why is useful.
When deciding if to generate a data out queue for the first sequence
the test was wrong.
We should not check if INITIAL_R2T is NO and IMMEDIATE_DATA=NO.
Immediate data does not matter here.
What we should check is IF we have more data we need to send and IF
INITIAL_R2T allows us to send more data, then we generate a train of DATA-OUT.
If MaxRecvDataSegmentLength is less than FirstBurstLength we will often have
to send unsolicited data as both ImmediateData and also as unsolicited
DATA-OUT PDUs.
Example:
Assume Target has responded :
MaxRecvDataSegmentLength = 8k
FirstBurstLength = 64k
ImmediateData=YES
InitialR2T=NO
Then this should generate the following sequence :
I->T ISCSI_COMMAND + 8K of immediate data. F-Bit is not set.
I->T DATA-OUT 8K
I->T DATA-OUT 8K
I->T DATA-OUT 8K
I->T DATA-OUT 8K
I->T DATA-OUT 8K
I->T DATA-OUT 8K
I->T DATA-OUT 8K. Final PDU in sequence so F-bit is set.
T->I R2T
...
If we do a write that spans more than first-burst-length amount of data
and we can use immediate data.
This will lead to a sequence
I->T SCSI_COMMAND + furst_burst_length of immediate data
T->I R2T
I->T DATA-OUT with the remainder of the data.
T->I SCSI_RESPONSE
In this situation we still have to set the F-bit in the flags for the ISCSI_COMMAND.
The F-bit indicates that the PDU is the final PDU in the current sequence
and is what will trigger the target to process what it has currently received
after which the target will either respond with a SCSI-RESULT or DATA-IN if this
was the final sequence of the command,
Or in the case this was not the last sequence, then the target will send a R2T
to request the next sequence for this command.
In this scenario above we have two sequences.
the first sequence is the SCSI_COMMAND with immediate data and since it has filled the full amount of immediate data and can not send any more data until an R2T, this means this pdu ends the sequence and thus has the F-bit set.
Once we receive the R2T the second sequence starts, which also will have the F-bit set in the PDU.
This fixes the IMMEDIATE_DATA_YES case if the paylaod did
not fit into the first PDU and fixes no unsolicited data
sent out iff IMMEDIATE_DATA_NO and INITIAL_R2T_NO.
Signed-off-by: Peter Lieven <pl@kamp.de>
set the cmdsn in the pdu struct so we can compare with
maxcmdsn when sending to socket even if data-out pdus
do not carry a cmdsn on the wire.
if we would not set pdu->cmdsn comparsion with
iscsi->maxcmdsn would cause a deadlock after
maxcmdsn increases to 2^31.
Signed-off-by: Peter Lieven <pl@kamp.de>
Remove the size field as it is not used. If we would keep it
we would have to calculate it in scsi_task_set_iov_in/out which
would add unneccassry wals to the iovec array.
Signed-off-by: Peter Lieven <pl@kamp.de>
The send logic was completely broken for any cases except
ISCSI_INITIAL_R2T_NO and ISCSI_IMMEDIATE_DATA_YES.
The final flag was set wrong or no data was sent.
It was also broken if the data did not fit into the cmd_pdu as
the consecutive pdus did not have the scsi_cbdata set which
lead to a segfault in iscsi_get_user_out_buffer().
Unfortunately we need to include scsi-lowlevel.h again in iscsi-private.h.
This should be fixed asap by introduction of an iscsi_task struct
to avoid to store iscsi relevant data in the scsi_task.
Signed-off-by: Peter Lieven <pl@kamp.de>
Conflicts:
lib/iscsi-command.c
Signed-off-by: Peter Lieven <pl@kamp.de>
obsolete the old api.
After discussions, It is probably not the right thing to do.
Lets leave the old api as is. Most simpler applications will
continue to pass a single linear buffer to the iscsi_<send-data-out-to-device>_task() for convenience so it would be wrong to force them all to
migrate to amore complex iovector api.
Convert any linear buffers, if provided, to a one element data-out iovector
if a buffer was provided.
This patch fixes a deadlock case where all available
cmdsns have been used for command PDUs which need
additional Data-OUT PDUs to succeed (e.g. a write16
which is larger than first_burst_len).
In this case the target will never increase the maxcmdsn
leading to a deadlock in iscsi_write_to_socket().
If we receive the R2T for such a write request we will
queue the Data-OUT PDUs but at the end of queue. As
a result they will never be sent as the outqueue is already
stuck.
We fix this by sorting the outqueue by ascending itt.
Signed-off-by: Peter Lieven <pl@kamp.de>
This finally makes T1040 trigger the cmdsn overflow deadlock.
Its a bad idea to mangle on negotiated parameters as this leads
to protocol errors.
We also need to avoid overlapping writes as this leads also
to protocol errors.
Additionally we test with and with (if available) immediate data.
Signed-off-by: Peter Lieven <pl@kamp.de>
