When scanning for the CONTROL mode page we must also check that SPF==0
since otherwise we might pick up CONTROL EXTENSIONS or other subpages
that may be returned.
Signed-off-by: Ronnie Sahlberg <ronniesahlberg@gmail.com>
I didn't set up the transfer length properly for the vectored SG_IO
support in the previous patch, which makes some implementations
of the ioctl unhappy. Fix this up per the spec.
Command like PERSISTENT RESERVE OUT fill out DATA OUT data in their
CDB setup routine, but the SG_IO code doesn't look at that, leading
to a segfault when issueing such commands. Fix this by copying over
some code from the iSCSI path.
Signed-off-by: Christoph Hellwig <hch@lst.de>
We support SG_IO on various block devices, including but not limited to:
SCSI disks, CDROMs and tapes, virtio-blk and nvmve.
Instead of checking a filename prefix just treat anything that isn't
an iscsi:// url as a device node. The ioctl checks after open will weed
out devices (or files) that don't support SG_IO.
Signed-off-by: Christoph Hellwig <hch@lst.de>
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>
Avoid that the DPO / DPOFUA tests triggers a NULL pointer dereference
if the MODE SENSE command in these tests fails.
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Avoid that Valgrind reports complaints similar to the following:
Conditional jump or move depends on uninitialised value(s)
at 0x405097: send_scsi_command (iscsi-support.c:240)
by 0x40904B: reserve6_conflict (iscsi-support.c:1915)
by 0x42231C: test_reserve6_logout (test_reserve6_logout.c:63)
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)
by 0x404B43: main (iscsi-test-cu.c:1292)
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>
This allows all tests to properly work on /dev/sg nodes instead
of segfaulting when a test is written the iSCSI-specific APIs.
Signed-off-by: Christoph Hellwig <hch@lst.de>
The variable user in struct iscsi_url is a character array, not a pointer.
Therefore its address will never be NULL.
When libscsi is built using clang instead of gcc, those errors are reported:
iscsi-perf.c:256:17: error:
comparison of array 'iscsi_url->user' not equal to a null
pointer is always true [-Werror,-Wtautological-pointer-compare]
iscsi-dd.c:272:17: error:
comparison of array 'iscsi_url->user' not equal to a null
pointer is always true [-Werror,-Wtautological-pointer-compare]
iscsi-dd.c:331:17: error:
comparison of array 'iscsi_url->user' not equal to a null
pointer is always true [-Werror,-Wtautological-pointer-compare]
ld_iscsi.c:99:18: error:
comparison of array 'iscsi_url->user' not equal to a null
pointer is always true [-Werror,-Wtautological-pointer-compare]
Fix those errors and also similar code patterns in aros/iscsi-ls.c and
test-tool/iscsi-support.c.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Clang whinges about an empty loop body when it sees code like
while (i = 0; i++; i < 2);
but in test_preventallow_*.c this looks intentional, so move the
semi-colon to a line of its own to make clang happy.
Signed-off-by: Sitsofe Wheeler <sitsofe@yahoo.com>
If rand_key() is called twive within the same second it would return the
same key both times. Not very random.
Redo how rand_key() works to make it more likely to be random and more likely
that two consequtive calls do not yield the same result.
Reported-by: CyberLoiter <yanming.xiao@gmail.com>
Signed-off-by: Ronnie Sahlberg <ronniesahlberg@gmail.com>
ascq is NULL if there are no ascqs provided for this failure mode.
Do not try to dereference the 0-th element in this array before checking
that the array has at least one element.
Signed-off-by: Ronnie Sahlberg <ronniesahlberg@gmail.com>
Remove the flags tests for READ* and replace them with a test for the DPO
and FUA bits.
IF the device claims DPOFUA support in modesense then the READ* CDBs
MUST allow these two flags. IF the device does NOT claim DPOFUA then any
READ* CDB with these flags must fail with invalod field in cdb.
Signed-off-by: Ronnie Sahlberg <ronniesahlberg@gmail.com>
There is no agreement among the T10 committee whether a SCSI target should
report "invalid opcode", "invalid field in CDB" or "invalid field in
parameter list" if the opcode consists of two bytes. Hence accept all three
sense codes for two-byte opcodes. For more information see also Frederick
Knight, RE: INVALID COMMAND OPERATION CODE, T10 Reflector, 16 May 2008
(http://t10.org/ftp/t10/t10r/2008/r0805167.htm).
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
In the READ CAPACITY response support for logical block provisioning
is indicated via the LBPME (logical block provisioning management
enabled) bit. Since the logical block provisioning VPD page (B2h)
is optional, only query it if LBPME = 1.
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
According to RFC 3720 the data associated with a SCSI WRITE command
is sent via Data-Out PDU's. Update log texts accordingly and also
make the capitalization of DataSN consistent with RFC 3720.
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
A quote from SPC-4: "When using the MODE SENSE command, a
parameters saveable (PS) bit set to one indicates that the mode
page may be saved by the logical unit in a nonvolatile, vendor
specific location. A PS bit set to zero indicates that the device
server is not able to save the supported parameters. When using
the MODE SELECT command, the PS bit is reserved."
Hence clear the PS bit after having queried a mode page via MODE
SENSE and before changing it via MODE SELECT.
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Add 0x2701/0x2702 to the list of valid ASCQ values we accept for devices
that are write protected.
Signed-off-by: Ronnie Sahlberg <ronniesahlberg@gmail.com>
Some implementations may send oversized data coming back from Inquiry.
Warn about this instead of failing the test but then perform additional
checks that the padding MUST be zero or else fail the test.
Signed-off-by: Ronnie Sahlberg <ronniesahlberg@gmail.com>
valgrind does not know that sense will be initialized by the ioctl
so we need to to it explicitely to keep it from warning us.
Signed-off-by: Ronnie Sahlberg <ronniesahlberg@gmail.com>