1. 24 2月, 2020 19 次提交
  2. 23 2月, 2020 18 次提交
  3. 21 2月, 2020 3 次提交
    • M
      virDomainNetDefClear: Free @persistent name · 2ab278ec
      Michal Privoznik 提交于
      The persistent alias name @persistent is allocated in
      virDomainNetDefParseXML() but never freed.
      
      ==119642== 22 bytes in 2 blocks are definitely lost in loss record 178 of 671
      ==119642==    at 0x483579F: malloc (vg_replace_malloc.c:309)
      ==119642==    by 0x58F89F1: xmlStrndup (in /usr/lib64/libxml2.so.2.9.9)
      ==119642==    by 0x4BA3B74: virXMLPropString (virxml.c:520)
      ==119642==    by 0x4BDB0C5: virDomainNetDefParseXML (domain_conf.c:11876)
      ==119642==    by 0x4BF9EF4: virDomainDefParseXML (domain_conf.c:21196)
      ==119642==    by 0x4BFCD5B: virDomainDefParseNode (domain_conf.c:21943)
      ==119642==    by 0x4BFCC36: virDomainDefParse (domain_conf.c:21901)
      ==119642==    by 0x4BFCCCB: virDomainDefParseFile (domain_conf.c:21924)
      ==119642==    by 0x114A9D: testCompareXMLToArgv (qemuxml2argvtest.c:452)
      ==119642==    by 0x13894F: virTestRun (testutils.c:143)
      ==119642==    by 0x11F46E: mymain (qemuxml2argvtest.c:1316)
      ==119642==    by 0x13A60E: virTestMain (testutils.c:839
      
      Fixes: fb0509d0Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      2ab278ec
    • M
      virDomainFSDefFree: Unref private data · d8b4f70e
      Michal Privoznik 提交于
      The privateData object is allocated in virDomainFSDefNew() but
      never unref'd.
      
      ==119642== 480 bytes in 20 blocks are definitely lost in loss record 656 of 671
      ==119642==    at 0x4837B86: calloc (vg_replace_malloc.c:762)
      ==119642==    by 0x57806A0: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.6000.7)
      ==119642==    by 0x4AE7392: virAllocVar (viralloc.c:331)
      ==119642==    by 0x4B64395: virObjectNew (virobject.c:241)
      ==119642==    by 0x48F1464: qemuDomainFSPrivateNew (qemu_domain.c:1427)
      ==119642==    by 0x4BBF004: virDomainFSDefNew (domain_conf.c:2307)
      ==119642==    by 0x4BD859A: virDomainFSDefParseXML (domain_conf.c:11217)
      ==119642==    by 0x4BF9DD1: virDomainDefParseXML (domain_conf.c:21179)
      ==119642==    by 0x4BFCD5B: virDomainDefParseNode (domain_conf.c:21943)
      ==119642==    by 0x4BFCC36: virDomainDefParse (domain_conf.c:21901)
      ==119642==    by 0x4BFCCCB: virDomainDefParseFile (domain_conf.c:21924)
      ==119642==    by 0x114A9D: testCompareXMLToArgv (qemuxml2argvtest.c:452)
      
      Fixes: 5120577eSigned-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      d8b4f70e
    • L
      conf: extra validation for <port isolated='yes'/> · ef8de28c
      Laine Stump 提交于
      During the hypervisor-agnostic validation of network devices, verify
      that the interface type is either "network" or "bridge", and that if
      there is any <virtualport>, that it doesn't have any type associated
      with it.
      
      This needs to be done both for the parse-time validation and for
      runtime validation (after a port has been acquired from any associated
      network), because an interface with type='network' could have an
      actual type at runtime of "hostdev" or "direct", neither of which
      support isolated='true' (yet). Likewise, if an interface is
      type='network', then at runtime a <virtualport> with a type that
      doesn't support isolated='yes' (e.g. "openvswitch", "802.1Qbh" -
      currently *none* of the available virtualport types support it)
      Signed-off-by: NLaine Stump <laine@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      ef8de28c