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>
As far as I know SPC-4 does not allow unaligned unmap requests to
fail. The only phrase I found in SPC-4 about unaligned unmap
requests is the following: "An unmap request with a starting LBA
that is not optimal may result in unmap operations on fewer LBAs
than requested." Hence check that unaligned unmap requests succeed.
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
From the SPC-4 paragraph about WRITE SAME(10): "The WRITE SAME (10)
command requests that the device server transfer a single logical
block from the Data-Out Buffer [ ... ]". Hence always pass a data
buffer when sending a WRITE SAME(10) command.
Set the NDOB bit in the WRITE SAME(16) command if no data out buffer
is present.
Signed-off-by: Bart Van Assche <bvanassche@acm.org>