Describe the reason again:
A WRITE16 command[w] handles R2T, and queues DATAOUT PDU m,x,y,z:
outqueue->DATAOUT[x]->DATAOUT[y]->DATAOUT[z]...
outqueue_current->DATAOUT[m]
waitqueue->WRITE16[w]...
1, Once x, y, z gets released in initiator side, the target still expects the remaining
DATAOUT PDUs.
2, Once command w timeout and callback to uplayer, uplayers usually releases memory of
iscsi task(include memory referenced by iovec.iov_base). DATAOUT[m] would access
invalid memory iovce.iov_base.
So invoke WRITEx command callback until draining DATAOUT PDUs.
Co-developed-by: Rui Zhang <zhangrui.1203@bytedance.com>
Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
Once error occurs on socker read/write, libiscsi tries to reconnect
silently. Add necessary log message for this case.
Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
Now we have more friendly opcode message once error occurs:
libiscsi:1 command timed out from waitqueue [...]
libiscsi:2 PDU header: 01 c1 ... e9 88[READ16] 00 00 00 ...
^(human readable opcode string)
Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
Distinguish command timeout from outqueue or waitqueue. For example,
A command sequence: ...NOP,READ,WRITE...
NOP OUT command has no dependence on backend media, it is expected to
response soon. Once NOP timeout in libiscsi:
a, the command is already sent to target, the target side does *not*
response.
b, the command is still pending in libiscsi.
Separate the two cases for trouble shooting.
Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
Users need to check if a task is queued to send (not sent yet)
before invoking functions such as iscsi_task_mgmt_abort_task_async.
Otherwise, because task management requests are automatically
treated as "immediate", a request to abort a task is sent before
the task itself.
if (iscsi_scsi_is_task_in_outqueue(iscsi_, task_)) {
iscsi_scsi_cancel_task(iscsi_, task_);
} else {
iscsi_task_mgmt_abort_task_async(iscsi_, task_, AbortCb, context_);
}
The blocks may exceed the block limits offered by the target,
query unmap/write zero max blocks by inquiry
SCSI_INQUIRY_PAGECODE_BLOCK_LIMITS command, than use a loop to do the
job.
Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
The new tool 'iscsi-md5sum' is used to calculate MD5 value of an iSCSI
target. This help users to verify data at range [LBA, Length).
For example, double-write on a RAID1 of 2 iSCSI targets, a daemon
process runs iscsi-md5sum to check data periodically.
Originally, we have to use several steps to achieve:
1, use iscsiadm to login.(root privilege required)
2, use dd(dd if=/dev/sdX of=/TMPPATH bs=4k count=LENGTH skip=LBA)
to dump data. (root privilege required, additional disk space required)
3, use md5sum to calculate MD5 value
4, remove data.
Instead, a single command iscsi-md5sum without root privilege is enough.
Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
The new tool 'iscsi-discard' is used to excute unmap or write zeros
on an ISCSI target. The parameters look like the command 'blkdiscard'
(from util-linux).
Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
HEX format is friendly to iSCSI utils, for example:
./iscsi-inq -e 0x1 -c 0xb1 iscsi://...
atoi supports decimal only, this example does not work.
Use strtol(nptr, NULL, 0) to auto-detect format, then this works fine.
Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
When execute iscsi_task_mgmt_lun_reset_async function,
pdus are already removed from waitpdu list. In iscsi_service
function, this will call iscsi_process_pdu and release
pdu from waitpdu again, which cause segmentation fault.
Whether waitpud list is NULL should be checked here to avoid
the problem.
Signed-off-by: geruijun <geruijun@huawei.com>
If invalid option is input with iscsi-ls，such as "iscsi-ls -a iscsi://", the command just stuck here and do not print useful information for the user to correct.
Fix this problem with getopt_long.
According to the man page and help info, --debug=integer can specify the
debug_level, while it would report following error:
iscsi-swp --debug=1
iscsi-swp: option '--debug' doesn't allow an argument
According to the man page and help info, --debug=integer can specify the
debug_level, while it would report following error:
iscsi-inq --debug=2
iscsi-inq: option '--debug' doesn't allow an argument
It's because the iscsi-inq code did not handle this parameters
correctly. So here we just correct it.
Signed-off-by: Wenchao Hao <haowenchao@huawei.com>
If a test sets the use_immediate_data parameter to ISCSI_IMMEDIATE_DATA_NO
for the iSCSI context, then the test expects that a data associated with
the Write command to be sent in a separate PDU.
But if for execute the command it is necessary to login on a target then
the use_immediate_data was previously set, will be rewrite during
the processing of the Login Response packet.
This happen during the iSCSI.iSCSIdatasn.iSCSIDataSnInvalid
(test_iscsi_datasn_invalid.c) test:
--> iSCSI 114 SCSI: Write(10) LUN: 0x01 (LBA: 0x00000064, Len: 1)
<-- iSCSI 114 Ready To Transfer
--> iSCSI 578 SCSI: Data Out LUN: 0x01 (Write(10) Request Data)
--> iSCSI 550 Login Command
Here we lose use_immediate_data value for iSCSI session.
<-- iSCSI 426 Login Response (Success)
--> iSCSI 114 SCSI: Test Unit Ready LUN: 0x01
<-- iSCSI 114 SCSI: Response LUN: 0x01 (Test Unit Ready) (Good)
And this Write command includes payload into iSCSI PDU packet, but should not do it.
--> iSCSI 578 SCSI: Write(10) LUN: 0x01 (LBA: 0x00000064, Len: 1)SCSI: Data Out LUN: 0x01 (Write(10) Request Data)
<-- iSCSI 114 SCSI: Response LUN: 0x01 (Write(10)) (Good)
--> iSCSI 114 SCSI: Write(10) LUN: 0x01 (LBA: 0x00000064, Len: 2)
<-- iSCSI 114 Ready To Transfer
--> iSCSI 578 SCSI: Data Out LUN: 0x01 (Write(10) Request Data)
--> iSCSI 626 SCSI: Data Out LUN: 0x01 (Write(10) Request Data)
Signed-off-by: Sergey Samoylenko <s.samoylenko@yadro.com>
In iscsi_send_data_out() a PDU is allocated, but there is no error
handling logic to free it if the PDU cannot be queued.
iscsi_allocate_pdu() may allocate memory for the PDU. This memory may be
leaked if iscsi_queue_pdu() fails since there is no call to free it.
Orignally there was a free() call but it was removed as a part of a
cleanup adding checks for NULL pdu callbacks.
Fixes: 423b82efa4 ("pdu: check callback for NULL everywhere")
Signed-off-by: Raphael Norwitz <raphael.norwitz@nutanix.com>
iscsi-pr uses libiscsi to connect target and issues PR command.
In most cases, iscsi-pr use the same parameters as sg_persist(from sg3-utils).
For example, use iscsi-pr to dump keys by command:
~# ./utils/iscsi-pr --read-keys iscsi://192.168.122.44/iqn.2003-01.org.linux-iscsi.bytedance.x8664:sn.a6b7bff3d509/0 -i iqn.2005-03.org.open-iscsi:12345678
PR generation=0x20, 19 registered reservation keys follow:
0xabcd1234
0xabcd
0xabcd
0xabc
A few command is not implemented in this patch, add them if necessary
in future.
Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
