1. 23 2月, 2020 8 次提交
  2. 21 2月, 2020 9 次提交
    • 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
    • L
      qemu: support updating <port isolated='yes|no'/> during device update · db7f2628
      Laine Stump 提交于
      This setting can be updating very easily on an already active
      interface by just changing it in sysfs. If the bridge used for
      connection is also changed, there is no need to separately update it,
      because the new setting isf done as a part of connecting to the bridge
      anyway.
      Signed-off-by: NLaine Stump <laine@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      db7f2628
    • L
      qemu/lxc: plumb isolatedPort from config down through bridge attachment · 2b8fd733
      Laine Stump 提交于
      This patch pushes the isolatedPort setting from the <interface> down
      all the way to the callers of virNetDevBridgeAddPort(), and sets
      BR_ISOLATED on the port (using virNetDevBridgePortSetIsolated()) after
      the port has been successfully added to the bridge.
      Signed-off-by: NLaine Stump <laine@redhat.com>
      Signed-off-by: NLaine Stump <laine@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      2b8fd733
    • L
      network: propagate <port isolated='yes'/> between network and domain · de7c347d
      Laine Stump 提交于
      Similar to the way that the <vlan>, <bandwidth>, and <virtualport>
      elements and the trustGuestRxFilters attribute in a <network> (or in
      the appropriate <portgroup> element of a <network> can be applied to a
      port when it is allocated for a domain's network interface, this patch
      checks for a configured value of <port isolated="yes|no"/> in
      either the domain <interface> or in the network, setting isolatedPort
      in the <networkport> to the first one it finds (the setting from the
      domain's <interface> is preferred). This, in turn, is passed back to
      the domain when a port is allocated, so that the domain will use that
      setting.
      
      (One difference from <vlan>, <bandwidth>, <virtualport>, and
      trustGuestRxFilters, is that all of those can be set in a <portgroup>
      so that they can be applied only to a subset of interfaces connected
      to the network. This didn't really make sense for the isolated setting
      due to the way that it's implemented in Linux - the BR_ISOLATED flag
      will prevent traffic from passing between two ports that both have
      BR_ISOLATED set, but traffic can still go between those ports and
      other ports that *don't* have BR_ISOLATED. (It would be nice if all
      traffic from a BR_ISOLATED port could be blocked except traffic going
      to/from a designated egress port or ports, but instead the entire
      feature is implemented as a single flag. Because of this, it's really
      only useful if all the ports on a network are isolated, so setting it
      for a subset has no practical utility.)
      Signed-off-by: NLaine Stump <laine@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      de7c347d
    • L
      conf: parse/format <port isolated='yes|no'/> · 31d95b18
      Laine Stump 提交于
      This is a very simple thing to parse and format, but needs to be done
      in 4 places, so two trivial utility functions have been made that can
      be called from all the higher level parser/formatters:
      
        <domain><interface>
        <domain><interface><actual> (only in domain status)
        <network>
        <networkport>
      Signed-off-by: NLaine Stump <laine@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      31d95b18
    • L
      util: query/set BR_ISOLATED flag on netdevs attached to bridge · a378d8fa
      Laine Stump 提交于
      When this flag is set for an interface attached to a bridge, traffic
      to/from the specified interface can only enter/exit the bridge via
      another attached interface that *doesn't* have the BR_ISOLATED flag
      set. This can be used to permit guests to communicate with the rest of
      the network, but not with each other.
      Signed-off-by: NLaine Stump <laine@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      a378d8fa
    • L
      qemu: save/restore original error when recovering from failed bridge attach · 3f8b57a6
      Laine Stump 提交于
      Not only was the original error code destroyed in the case of
      encountering an error during recovery from a failed attach to the
      bridge (and then *that* error was destroyed by logging a *second*
      error about the failure to recover - virNetDevBridgeAddPort() already
      logs an error, so the one about failing to recover was redundant), but
      if the recovery was successful, the function would then return success
      to the caller even though it had failed.
      
      Fixes: 2711ac87
      (overwritten errors were introduced along with this functionality)
      Fixes: 6bde0a1a
      (the wrong return value was introduced by a refactor)
      Signed-off-by: NLaine Stump <laine@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      3f8b57a6
  3. 20 2月, 2020 10 次提交
  4. 19 2月, 2020 2 次提交
  5. 18 2月, 2020 4 次提交
  6. 14 2月, 2020 7 次提交