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>
Create a wrapper for sending scsi_commands so that we can hide the
libiscsi function far away from the "opcode" helpers.
This means we only have a single place later to switch to a different
type of device, such as a SG_IO one.
Signed-off-by: Ronnie Sahlberg <ronniesahlberg@gmail.com>
Switch orwrite helpers to use _command_async instead of calling _orwrite_sync()
to prepare for switching to non-iscsi targets. Use the new check_result API
so that we only need a single helper function for ORWRITE instead of one
helper for each expected result.
Signed-off-by: Ronnie Sahlberg <sahlberg@localhost>
Many/most all SCSI helpers do pretty much the same checking for the SCSI
result and status. Break this out into a separate helper that we can use
to reduce code duplication.
Signed-off-by: Ronnie Sahlberg <sahlberg@localhost>
This issue was introduced via patch "pdu: introduce ISCSI_PDU_CORK_WHEN_SENT"
on June 13, 2014 (commit 99585b6996).
Valgrind reported this use-after-free as follows:
Invalid read of size 4
at 0x5267606: iscsi_write_to_socket (socket.c:721)
by 0x5267A72: iscsi_service (socket.c:823)
by 0x526827C: event_loop (sync.c:67)
by 0x52698A4: iscsi_compareandwrite_sync (sync.c:823)
by 0x408111: compareandwrite (iscsi-support.c:1752)
by 0x4139E2: test_compareandwrite_simple (test_compareandwrite_simple.c:88)
by 0x503D260: ??? (in /usr/lib64/libcunit.so.1.0.1)
by 0x503D578: ??? (in /usr/lib64/libcunit.so.1.0.1)
by 0x503D8B5: CU_run_all_tests (in /usr/lib64/libcunit.so.1.0.1)
by 0x4046C6: main (iscsi-test-cu.c:1241)
Address 0x639f258 is 8 bytes inside a block of size 256 free'd
at 0x4C291E7: free (vg_replace_malloc.c:473)
by 0x525321B: iscsi_free (init.c:68)
by 0x52532F0: iscsi_sfree (init.c:110)
by 0x5257AD9: iscsi_free_pdu (pdu.c:179)
by 0x5267601: iscsi_write_to_socket (socket.c:719)
by 0x5267A72: iscsi_service (socket.c:823)
by 0x526827C: event_loop (sync.c:67)
by 0x52698A4: iscsi_compareandwrite_sync (sync.c:823)
by 0x408111: compareandwrite (iscsi-support.c:1752)
by 0x4139E2: test_compareandwrite_simple (test_compareandwrite_simple.c:88)
by 0x503D260: ??? (in /usr/lib64/libcunit.so.1.0.1)
by 0x503D578: ??? (in /usr/lib64/libcunit.so.1.0.1)
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Cc: Peter Lieven <pl@kamp.de>
This commit fixes two related issues in the ld_iscsi example with
largefile support.
The first issue appears when building libiscsi against the glibc C
library, with the flags -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64:
{standard input}: Assembler messages:
{standard input}:2774: Error: symbol `__fxstat64' is already defined
{standard input}:2850: Error: symbol `__lxstat64' is already defined
{standard input}:2938: Error: symbol `__xstat64' is already defined
This is due to the fact that when _FILE_OFFSET_BITS=64 is passed, the
*64() functions are defined by the C library as aliases to the
non-64*() functions, because those ones directly support large files
(i.e 64 bits).
The second issue appears when building libiscsi against the uClibc C
library, in a configuration that doesn't have largefile support. In
this case, the ld_iscsi that tries to use stat64 or some other *64()
functions cannot build, because such functions are not provided by the
C library. Of course, ld_iscsi does not need to wrap the *64()
functions in such a situation, because they do not exist.
This commit fixes those problems by enclosing the *64() related code
of ld_iscsi in the following compile time conditional:
This ensures that the *64() function handling is here only if
largefile support is available and enabled (_LARGEFILE_SOURCE64) and
if non-*64() functions are not already 64 bits capable (in which case
the 64*() functions are just aliases for the non-64*() ones).
See also
http://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html
for more details about the meaning of those macros.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The current test in configure.ac for CUnit uses AC_TRY_RUN, which
doesn't work in a cross-compilation context, because we can't run on
the build machine the binaries that are built for the target. In
addition, the current logic assumes CUnit is available when the
AC_TRY_RUN test cannot be used (e.g in a cross-compilation case).
Since we actually don't care about *running* but only about testing
whether a simple program include the CUnit header file and linking
against the cunit library works, simply use AC_TRY_LINK() instead of
AC_TRY_RUN().
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When trying to compile libiscsi on a 32 bit Ubuntu 10.04 with gcc 4.4.3
errors like the following are produced:
test_get_lba_status_beyond_eol.c:45: error: integer constant is too
large for ‘long’ type
This is because we don't specify that we are explictly compiling to the
c99 standard and as such gcc defaults to gnu90 standard. This in turn
means the maximum default type of integer literals is unsigned long int
which not big enough to hold the literal on a 32 bit architecture.
Fix this by adding the ULL suffix to all large integer literals.
Signed-off-by: Sitsofe Wheeler <sitsofe@yahoo.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>
Support for WRITE SAME with NUMBER OF LOGICAL BLOCKS = 0 is optional.
Hence set NUMBER OF LOGICAL BLOCKS to 0 if this value is supported
and set this parameter to 1 otherwise.
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
