Fixes the Coverity Scan Report:
** 1414521 Uninitialized scalar field
CID 1414521 (#1 of 1): Uninitialized scalar field (UNINIT_CTOR)
3. uninit_member: Non-static class member m_writeRc is not initialized in this constructor nor in any functions that it calls.
Signed-off-by: Amit Kumar amitkuma@redhat.com
this change also silence some cppcheck warnings: we fail to rlease
references to MultiAioCompletionImpl in some of the error handling paths.
Signed-off-by: Kefu Chai <kchai@redhat.com>
byteorder: use gcc intrinsics for byteswap
Reviewed-by: Jason Dillaman <dillaman@redhat.com>
Reviewed-by: Casey Bodley <cbodley@redhat.com>
Reviewed-by: Sage Weil <sage@redhat.com>
if `rc` is not zero, the returned `ssize` is either garbage or
undefined. this silences warning from clang analyzer:
Assigned value is garbage or undefined
Signed-off-by: Kefu Chai <kchai@redhat.com>
Some variables have been already free'd by calling
release(), no need to call delete() again on them.
CID 1396200 (#1 of 1): Double free (USE_AFTER_FREE)
double_free: Calling operator delete frees pointer
getxattr_completion which has already been freed.
CID 1396206 (#1 of 1): Double free (USE_AFTER_FREE)
double_free: Calling operator delete frees pointer
getxattr_completion which has already been freed.
CID 1396214 (#1 of 1): Double free (USE_AFTER_FREE)
double_free: Calling operator delete frees pointer
stat_completion which has already been freed.
CID 1396218 (#1 of 1): Double free (USE_AFTER_FREE)
double_free: Calling operator delete frees pointer
stat_completion which has already been freed.
Signed-off-by: Danny Al-Gaaf <danny.al-gaaf@bisect.de>
prior to this change, libcommon is a convenient library which gets
linked into librados, librbd and libcephfs and all ceph executables.
this incurs some problems:
- double dose of libcommon in memory space and HDD: waste of memory
and disk space.
- if an application links to two libraries including libcommon at the
same time. take librados and libcephfs as an example, they could
interfere with each other by changing the other guy's status.
after this change, libcommon is tuned into a shared library and
renamed to libceph-common. it will be installed into $prefix/lib/ceph,
and packaged in librados2.
ceph.spec.in,debian/librados2.install: package libceph-common in
librados2.
CMakeLists.txt:
- do not link against libboost-* if not necessary.
- s/common/ceph-common/g
- install libceph-common into $prefix/lib/ceph
- set rpath to $prefix/lib/ceph
- link against ceph-common if an executable needs access to non public
symbols in ceph.
Signed-off-by: Kefu Chai <kchai@redhat.com>
Previous implementation was not always making sure that unlocking completed and this could lead to not unlocking at all in case the process wsa exiting before the Objecter did handle the async unlock request.
Signed-off-by: Sebastien Ponce <sebastien.ponce@cern.ch>
Usage of synchronous unlock in the completion callbacks was found to be a limitation for heavy parallel transfers sharing a single IoCtx
Signed-off-by: Sebastien Ponce <sebastien.ponce@cern.ch>
striped objects' truncation and removal is now using the rados asynchronous APIs and taking benefit of the parallelization they allow.
So far, the different rados objects inside a striped object where removed one by one via synchronous calls, and it was typically taking ages for big ones.
Signed-off-by: Sebastien Ponce <sebastien.ponce@cern.ch>
NObjectIterator::__EndObjectIterator is a static member variable
whose destructor deletes a pointer. librados.cc is the source file that
defines __EndObjectIterator. before this change rados cli is linked
against libradosstriper and librados. both of them include librados.cc.
that's why the dtor is called twice, hence double free when the dso
is closed and the static variables are destructed. in this change,
the librados.cc is moved out of libradosstriper, RadosClient.cc,
RadosXattrIter.cc and IoCtxImpl.cc kept as the OBJECT library, as
libradostriper is accessing the non-public symbols defined by them.
Fixes: http://tracker.ceph.com/issues/16504
Signed-off-by: Kefu Chai <kchai@redhat.com>
because libradosstriper does not put the `__attribute__ ((visibility
("default")))` specifier on the exported class/methods. we cannot
add the visibility to this library yet. the same applies to libcephfs.
Signed-off-by: Kefu Chai <kchai@redhat.com>
* no regression found, and there's a substantial reduction in the size of
generated librados library (both stripped and not).
* also remove the duplicated set_target_properties(librbd...) command
Signed-off-by: Kefu Chai <kchai@redhat.com>
and s/libradosstriper/radosstriper/ otherwise the created .so
filename would be liblibradosstriper.so with the default prefix.
Signed-off-by: Kefu Chai <kchai@redhat.com>
also respect BUILD_SHARED_LIBS instead of always building this lib as a
static library. and we install .so in rpm/deb packaging scripts.
Signed-off-by: Kefu Chai <kchai@redhat.com>
- drop the global
- do not memset!
- encode with features
- field names are different
- use get_period() method where appropriate
- fix is layout empty checks
Signed-off-by: Sage Weil <sage@redhat.com>
Using this function to judge whether copy data from bufferlist to
dst. It mainly used librados C interface to avoid copy data from librados
to caller.
Signed-off-by: Jianpeng Ma <jianpeng.ma@intel.com>
The symbols of lttng were exposed twice leading to error when launching executables using libradosstriper.
Signed-off-by: Sebastien Ponce <sebastien.ponce@cern.ch>
* do not hide the symbols in buffer.cc, as XioMessenger.cc is referencing
get_xio_mp().
* do not export private symbols from libcephfs.
Fixes: #10735
Co-authored-by: Danny Al-Gaaf <danny.al-gaaf@bisect.de>
Signed-off-by: Kefu Chai <kchai@redhat.com>
Fixes: #10758
write_full was returning ENOENT when the file did not exists, while it should just have created it without complaining.
Signed-off-by: Sebastien Ponce <sebastien.ponce@cern.ch>
The librados shared library was previously exporting all
symbols. librados public API methods are now explicitly
exported and all other symbols are hidden.
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
