1. 24 6月, 2019 2 次提交
  2. 04 10月, 2016 7 次提交
    • P
      maint: fix syntax-check sc_prohibit_int_ijk exclude rule · 84d35ef5
      Pavel Hrdina 提交于
      Fix the regex for excluding files for this syntax-rule.  The rule "include/"
      will not work, because we are matching the whole line like this
      "^(...|include/|...)$ so we need to use "include/libvirt/libvirt.+".  The second
      issue is that we are using only one '$' but there should be two of those at the
      end.  The last small adjustment is to escape dots '.' so it match only dot.
      Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
      (cherry picked from commit a94efa50)
      84d35ef5
    • E
      build: accomodate selinux 2.5 header API change · b25ca814
      Eric Blake 提交于
      Yet again, selinux has been adding const-correctness; this change
      is ABI-compatible, but breaks API, which affects us when we try to
      override things in our testsuite:
      
      ../../tests/securityselinuxhelper.c:307:24: error: conflicting types for 'selabel_open'
       struct selabel_handle *selabel_open(unsigned int backend,
                              ^~~~~~~~~~~~
      In file included from ../../tests/securityselinuxhelper.c:32:0:
      /usr/include/selinux/label.h:73:24: note: previous declaration of 'selabel_open' was here
      
      The problem is a new 'const' prior to the second parameter.
      
      Fix it the same way we did in commit 292d3f2d: check for the new
      const at configure time.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      (cherry picked from commit 5ea3a690)
      b25ca814
    • P
      build: add GCC 6.0 -Wlogical-op workaround · ec7040c0
      Pavel Hrdina 提交于
      fdstream.c: In function 'virFDStreamWrite':
      fdstream.c:390:29: error: logical 'or' of equal expressions [-Werror=logical-op]
              if (errno == EAGAIN || errno == EWOULDBLOCK) {
                                  ^~
      
      Fedora rawhide now uses gcc 6.0 and there is a bug with -Wlogical-op
      producing false warnings.
      
      https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69602
      
      Use GCC pragma push/pop and ignore -Wlogical-op for GCC that supports
      push/pop pragma and also has this bug.
      Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
      (cherry picked from commit d713a6b1)
      ec7040c0
    • M
      Initialize couple of variables. · 6a293aa2
      Michal Privoznik 提交于
      While trying to build with -Os couple of compile errors showed
      up.
      
      conf/domain_conf.c: In function 'virDomainChrRemove':
      conf/domain_conf.c:13666:24: error: 'ret' may be used uninitialized in this function [-Werror=maybe-uninitialized]
           virDomainChrDefPtr ret, **arrPtr = NULL;
                              ^
      Compiler fails to see that @ret is used only if set in the loop,
      but whatever, there's no harm in initializing the variable.
      
      In vboxAttachDrivesNew and _vboxAttachDrivesOld compiler thinks
      that @rc may be used uninitialized. Well, not directly, but maybe
      after some optimization. Yet again, no harm in initializing a
      variable.
      
      In file included from ./util/virthread.h:26:0,
                       from ./datatypes.h:28,
                       from vbox/vbox_tmpl.c:43,
                       from vbox/vbox_V3_1.c:37:
      vbox/vbox_tmpl.c: In function '_vboxAttachDrivesOld':
      ./util/virerror.h:181:5: error: 'rc' may be used uninitialized in this function [-Werror=maybe-uninitialized]
           virReportErrorHelper(VIR_FROM_THIS, code, __FILE__,              \
           ^
      In file included from vbox/vbox_V3_1.c:37:0:
      vbox/vbox_tmpl.c:1041:14: note: 'rc' was declared here
           nsresult rc;
                    ^
      Yet again, one uninitialized variable:
      
      qemu/qemu_driver.c: In function 'qemuDomainBlockCommit':
      qemu/qemu_driver.c:17194:9: error: 'baseSource' may be used uninitialized in this function [-Werror=maybe-uninitialized]
               qemuDomainPrepareDiskChainElement(driver, vm, baseSource,
               ^
      
      And another one:
      
      storage/storage_backend_logical.c: In function 'virStorageBackendLogicalMatchPoolSource.isra.2':
      storage/storage_backend_logical.c:618:33: error: 'thisSource' may be used uninitialized in this function [-Werror=maybe-uninitialized]
                             thisSource->devices[j].path))
                                       ^
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      (cherry picked from commit bde6e002)
      6a293aa2
    • M
      util: bitmap: clarify virBitmapLastSetBit() behavior for empty bitmaps · 598845b4
      Marc Hartmayer 提交于
      Before the variable 'bits' was initialized with 0 (commit
      3470cd86), the following bug was
      possible.
      
      A function call with an empty bitmap leads to undefined
      behavior. Because if 'bitmap->map_len == 0' 'unusedBits' will be <= 0
      and 'sz == 1'. So the non global and non static variable 'bits' would
      have never been set. Consequently the check 'bits == 0' results in
      undefined behavior.
      
      This patch clarifies the current version of the function by handling the
      empty bitmap explicitly. Also, for an empty bitmap there is obviously no
      bit set so we can just return -1 (indicating no bit set) right away. The
      explicit check for 'bits == 0' after the loop is unnecessary because we
      only get to this point if no set bit was found.
      Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
      Reviewed-by: NSascha Silbe <silbe@linux.vnet.ibm.com>
      Reviewed-by: NBjoern Walk <bwalk@linux.vnet.ibm.com>
      Signed-off-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>
      (cherry picked from commit 7cd01a24)
      598845b4
    • M
      Fix building with -Og · 5f71b6ed
      Martin Kletzander 提交于
      When building using -Og, gcc sees that some variables can be used
      uninitialized  It can be debatable whether it is possible with our
      codeflow, but functions should be self-contained and initializations are
      always good.  The return instead of goto is due to actualType being used
      in the cleanup.
      Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
      (cherry picked from commit 3470cd86)
      5f71b6ed
    • M
      qemu: Only use memory-backend-file with NUMA if needed · 7ed7246b
      Martin Kletzander 提交于
      If this reminds you of a commit message from around a year ago, it's
      41c2aa72 and yes, we're dealing with
      "the same thing" again.  Or f309db1f and
      it's similar.
      
      There is a logic in place that if there is no real need for
      memory-backend-file, qemuBuildMemoryBackendStr() returns 0.  However
      that wasn't the case with hugepage backing.  The reason for that was
      that we abused the 'pagesize' variable for storing that information, but
      we should rather have a separate one that specifies whether we really
      need the new object for hugepage backing.  And that variable should be
      set only if this particular NUMA cell needs special treatment WRT
      hugepages.
      
      Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1372153Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
      (cherry picked from commit 4372a7845acbc6974f6027ef68e7dd3eeb47f425)
      7ed7246b
  3. 30 6月, 2016 1 次提交
  4. 03 2月, 2016 1 次提交
  5. 02 2月, 2016 1 次提交
  6. 01 2月, 2016 1 次提交
  7. 19 1月, 2016 2 次提交
    • M
      virLogManagerDomainReadLogFile: Don't do dummy allocs · bce46d6a
      Michal Privoznik 提交于
      Since we pass dummy variables @fdout and @fdoutlen into
      virNetClientProgramCall() we make it alloc @fdout array (even
      though it's an array of 0 elements since vitlogd can hardly pass
      us some FDs at this stage). Nevertheless, it's an allocation not
      followed by free():
      
      ==29385== 0 bytes in 60 blocks are definitely lost in loss record 2 of 1,009
      ==29385==    at 0x4C2C070: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
      ==29385==    by 0x54B99EF: virAllocN (viralloc.c:191)
      ==29385==    by 0x56821B1: virNetClientProgramCall (virnetclientprogram.c:359)
      ==29385==    by 0x563B304: virLogManagerDomainReadLogFile (log_manager.c:272)
      ==29385==    by 0x217CD613: qemuDomainLogContextRead (qemu_domain.c:2485)
      ==29385==    by 0x217EDC76: qemuProcessReadLog (qemu_process.c:1660)
      ==29385==    by 0x217EDE1D: qemuProcessReportLogError (qemu_process.c:1696)
      ==29385==    by 0x217EE8C1: qemuProcessWaitForMonitor (qemu_process.c:1957)
      ==29385==    by 0x217F6636: qemuProcessLaunch (qemu_process.c:4955)
      ==29385==    by 0x217F71A4: qemuProcessStart (qemu_process.c:5152)
      ==29385==    by 0x21846582: qemuDomainObjStart (qemu_driver.c:7396)
      ==29385==    by 0x218467DE: qemuDomainCreateWithFlags (qemu_driver.c:7450)
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      (cherry picked from commit c03fbecc)
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      bce46d6a
    • M
      qemuProcessReadLog: Fix memmove arguments · 58832fe4
      Michal Privoznik 提交于
      So I can observe this crasher that with freshly started daemon
      (and virtlogd enabled) I am trying to startup a domain that
      immediately dies (because it's said to use huge pages but I
      haven't allocated a single one in the pool). Hardly reproducible
      with -O0 or under valgrind. But I just got lucky:
      
      ==20469== Invalid write of size 8
      ==20469==    at 0x4C2E99B: memcpy@GLIBC_2.2.5 (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
      ==20469==    by 0x217EDD07: qemuProcessReadLog (qemu_process.c:1670)
      ==20469==    by 0x217EDE1D: qemuProcessReportLogError (qemu_process.c:1696)
      ==20469==    by 0x217EE8C1: qemuProcessWaitForMonitor (qemu_process.c:1957)
      ==20469==    by 0x217F6636: qemuProcessLaunch (qemu_process.c:4955)
      ==20469==    by 0x217F71A4: qemuProcessStart (qemu_process.c:5152)
      ==20469==    by 0x21846582: qemuDomainObjStart (qemu_driver.c:7396)
      ==20469==    by 0x218467DE: qemuDomainCreateWithFlags (qemu_driver.c:7450)
      ==20469==    by 0x21846845: qemuDomainCreate (qemu_driver.c:7468)
      ==20469==    by 0x5611CD0: virDomainCreate (libvirt-domain.c:6753)
      ==20469==    by 0x125D9A: remoteDispatchDomainCreate (remote_dispatch.h:3613)
      ==20469==    by 0x125CB7: remoteDispatchDomainCreateHelper (remote_dispatch.h:3589)
      ==20469==  Address 0x27a52ad0 is 0 bytes after a block of size 5,584 alloc'd
      ==20469==    at 0x4C29F80: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
      ==20469==    by 0x9B8D1DB: xdr_string (in /lib64/libc-2.21.so)
      ==20469==    by 0x563B39C: xdr_virLogManagerProtocolNonNullString (log_protocol.c:24)
      ==20469==    by 0x563B6B7: xdr_virLogManagerProtocolDomainReadLogFileRet (log_protocol.c:123)
      ==20469==    by 0x164B34: virNetMessageDecodePayload (virnetmessage.c:407)
      ==20469==    by 0x5682360: virNetClientProgramCall (virnetclientprogram.c:379)
      ==20469==    by 0x563B30E: virLogManagerDomainReadLogFile (log_manager.c:272)
      ==20469==    by 0x217CD613: qemuDomainLogContextRead (qemu_domain.c:2485)
      ==20469==    by 0x217EDC76: qemuProcessReadLog (qemu_process.c:1660)
      ==20469==    by 0x217EDE1D: qemuProcessReportLogError (qemu_process.c:1696)
      ==20469==    by 0x217EE8C1: qemuProcessWaitForMonitor (qemu_process.c:1957)
      ==20469==    by 0x217F6636: qemuProcessLaunch (qemu_process.c:4955)
      
      This points to memmove() in qemuProcessReadLog(). Imagine we just
      read the following string from qemu:
      
      "abc\n2016-01-18T09:40:44.022744Z qemu-system-x86_64: Error\n"
      
      After the first pass of the while() loop in the
      qemuProcessReadLog() (in which we have taken the false branch in
      the if) @buf still points to the beginning of the string,
      @filter_next points to the beginning of the second line.  So we
      start second iteration because there is yet another newline
      character at the end. In this iteration @eol points to it
      actually. Now, the control gets inside true branch of if(). Just
      to remind you:
      
      got = 58
      filter_next = buf + 5,
      eol = buf + 58.
      
      Therefore skip = 54 which is correct. The message we want to skip
      is 54 bytes long. However:
      
      memmove(filter_next, eol + 1, (got - skip) +1);
      
      which is
      
      memmove(filter_next, eol + 1, 5)
      
      is obviously wrong as there is only one byte we can access, not 5!
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      (cherry picked from commit 105b51f4)
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      58832fe4
  8. 17 1月, 2016 1 次提交
  9. 15 1月, 2016 6 次提交
  10. 14 1月, 2016 5 次提交
  11. 13 1月, 2016 8 次提交
    • C
      build: fix distdir with wireshark disabled · e20dd2a4
      Cole Robinson 提交于
      Even though the Makefile has WITH_WIRESHARK guards, the _SOURCES
      variables are still processed when adding bits to the dist archive.
      
      plugin.c is a generated file that is only built when wireshark is
      enabled and it shouldn't be distributed, so use 'nodist'
      e20dd2a4
    • M
      qemuProcessCleanupChardevDevice: Don't unlink NULL paths · e988ba94
      Michal Privoznik 提交于
      So, you try to start a domain, but before we even get to the part
      where chardev part of qemu command line is generated (and
      possibly missing path to unix sockets is made up) an error occurs
      which results in calling qemuProcessStop. This will then try to
      clean up the mess and possibly ends up calling unlink(NULL).
      
      ==8085== Thread 3:
      ==8085== Syscall param unlink(pathname) points to unaddressable byte(s)
      ==8085==    at 0xA85EA57: unlink (in /lib64/libc-2.21.so)
      ==8085==    by 0x213D3C24: qemuProcessCleanupChardevDevice (qemu_process.c:2866)
      ==8085==    by 0x558D6B1: virDomainChrDefForeach (domain_conf.c:22924)
      ==8085==    by 0x213DA9AE: qemuProcessStop (qemu_process.c:5326)
      ==8085==    by 0x213DA2F2: qemuProcessStart (qemu_process.c:5190)
      ==8085==    by 0x2142957F: qemuDomainObjStart (qemu_driver.c:7396)
      ==8085==    by 0x214297DB: qemuDomainCreateWithFlags (qemu_driver.c:7450)
      ==8085==    by 0x21429842: qemuDomainCreate (qemu_driver.c:7468)
      ==8085==    by 0x5611B95: virDomainCreate (libvirt-domain.c:6753)
      ==8085==    by 0x125D9A: remoteDispatchDomainCreate (remote_dispatch.h:3613)
      ==8085==    by 0x125CB7: remoteDispatchDomainCreateHelper (remote_dispatch.h:3589)
      ==8085==    by 0x568BF41: virNetServerProgramDispatchCall (virnetserverprogram.c:437)
      ==8085==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
      ==8085==
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      e988ba94
    • J
      xenconfig: check return value of regcomp · 71daae96
      Jim Fehlig 提交于
      Commit ec63000a missed checking the return value of regcomp(),
      which coverity promptly identified.
      71daae96
    • M
      wireshark: Install into DESTDIR · 50078cfb
      Michal Privoznik 提交于
      Like everything we install, it should be prefixed with DESTDIR.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      50078cfb
    • J
      Xen: use correct domctl version in domaininfolist union · 6564de5e
      Jim Fehlig 提交于
      Commmit fd2e3c4c used the domctl version 8 structure for version 9
      in the xen_getdomaininfolist union, resulting in insufficient buffer
      size (and subsequent memory corruption) for the GETDOMAININFOLIST
      ioctl.
      Signed-off-by: NJim Fehlig <jfehlig@suse.com>
      6564de5e
    • C
      testutils: Fix coverity warning with REGENERATE_OUTPUT · ebfd6f45
      Cole Robinson 提交于
      - Don't double check for expectName
      - actual is always non-NULL by this point, so don't check it either
      ebfd6f45
    • C
      build: Kill tools/wireshark Makefiles · 3445acdb
      Cole Robinson 提交于
      Just handle it all in tools/Makefile.am. I verified the generated output
      looks similar to the pre patch output, but I didn't test it.
      3445acdb
    • M
      Expand $(wildcard) correctly · 8c67ab66
      Michal Privoznik 提交于
      So after da176bf6 and friend we have switched to $(wildcard
      some/path/*.xml) instead of enumerating the files explicitly.
      This is nice, however it makes distcheck build from VPATH fail.
      The reason is that it's is not obvious to what does the wildcard
      refer to: srcdir or builddir?
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      8c67ab66
  12. 12 1月, 2016 5 次提交
新手
引导
客服 返回
顶部