Avoid that Valgrind reports complaints similar to the following:
Syscall param writev(vector[...]) points to uninitialised byte(s)
at 0x5567087: writev (writev.c:49)
by 0x5265AE0: iscsi_iovector_readv_writev (socket.c:492)
by 0x52666B5: iscsi_write_to_socket (socket.c:710)
by 0x5266CCC: iscsi_service (socket.c:852)
by 0x526751F: event_loop (sync.c:67)
by 0x5269B41: iscsi_scsi_command_sync (sync.c:1153)
by 0x4050F6: send_scsi_command (iscsi-support.c:245)
by 0x408007: compareandwrite (iscsi-support.c:1512)
by 0x40B6AD: test_compareandwrite_dpofua (test_compareandwrite_dpofua.c:69)
by 0x503EC99: ??? (in /usr/lib/libcunit.so.1.0.1)
by 0x503EF27: ??? (in /usr/lib/libcunit.so.1.0.1)
by 0x503F2A5: CU_run_all_tests (in /usr/lib/libcunit.so.1.0.1)
Address 0xffeffff10 is on thread 1's stack
in frame #8, created by test_compareandwrite_dpofua (test_compareandwrite_dpofua.c:30)
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
While running the test tool I noticed that a significant number
of CPU cycles was spent in test_writesame10_unmap(). Rewrite the
comparison loop such that it needs fewer CPU cycles. Use the same
comparison code in test_writesame16_unmap().
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Only perform the test with 65536 blocks on block devices with at
least that number of blocks. Fix the 65536 block test log message.
Generalize the WRITE SAME(10) 256-block test log messages. Fix
interpretation of the MAXIMUM UNMAP BLOCK DESCRIPTOR COUNT field.
A quote from SPC-4: "If there is no limit on the number of UNMAP
block descriptors contained in the parameter data, then the device
server shall set the MAXIMUM UNMAP BLOCK DESCRIPTOR COUNT field to
FFFF_FFFFh."
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
- writesame10_unmap_until_end, writesame16_unmap, writesame16_unmap_until_end were doing an CU_ASSERT *PER-BYTE* in the verification phase,
which was very CPU-intensive. This change uses memcmp on a whole block which finishes much quicker.
If BLockLimits->MaxWriteSameLength is 0 (no limit) or >=256
then verify that both WRITESAME10 and WRITESAME16 can unmap with a
number of blocks == 2 byte field.
If not, then verify that a 256 block unmap results in INVALID FIELD IN CDB
If BLockLimits->MaxWriteSameLength is 0 (no limit) or >=65536
then verify that WRITESAME16 can unmap with a
number of blocks == 3 byte field.
If not, then verify that a 65536 block unmap results in INVALID FIELD IN CDB
From discussions on linux-scsi there are devices that support WRITESAME16
but where the implementation only looks at the low 2 bytes of the 4 bytes for
num-blocks in the CDB.
This added test aims to find and flag such devices.
