Lets not use a whitelist of UnitAttentions that we consume during the connect
phase. Instead we can just loop and fail after the 10th.
If there are more than 10 UAs then we have a problem, otherwise
just consume them all, forget them and then pass control back to the caller.
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>
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>