1. 20 2月, 2019 1 次提交
    • E
      domain: Fix unknown flags diagnosis in virDomainGetXMLDesc · 27c8fd74
      Eric Blake 提交于
      Many drivers had a comment that they did not validate the incoming
      'flags' to virDomainGetXMLDesc() because they were relying on
      virDomainDefFormat() to do it instead. This used to be the case
      (at least since 461e0f1a and friends in 0.9.4 added unknown flag
      checking in general), but regressed in commit 0ecd6851 (1.2.12),
      when all of the drivers were changed to pass 'flags' through the
      new helper virDomainDefFormatConvertXMLFlags(). Since this helper
      silently ignores unknown flags, we need to implement flag checking
      in each driver instead.
      
      Annoyingly, this means that any new flag values added will silently
      be ignored when targeting an older libvirt, rather than our usual
      practice of loudly diagnosing an unsupported flag.  Add comments
      in domain_conf.[ch] to remind us to be extra vigilant about the
      impact when adding flags (a new flag to add data is safe if the
      older server omitting the requested data doesn't break things in
      the newer client; a new flag to suppress data rather than enhancing
      the existing VIR_DOMAIN_XML_SECURE may form a data leak or even a
      security hole).
      
      In the qemu driver, there are multiple callers all funnelling to
      qemuDomainDefFormatBufInternal(); many of them already validated
      flags (and often only a subset of the full set of possible flags),
      but for ease of maintenance, we can also check flags at the common
      helper function.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
      27c8fd74
  2. 04 2月, 2019 1 次提交
  3. 28 1月, 2019 1 次提交
    • M
      lib: Use more of VIR_STEAL_PTR() · 5772885d
      Michal Privoznik 提交于
      We have this very handy macro called VIR_STEAL_PTR() which steals
      one pointer into the other and sets the other to NULL. The
      following coccinelle patch was used to create this commit:
      
        @ rule1 @
        identifier a, b;
        @@
      
        - b = a;
          ...
        - a = NULL;
        + VIR_STEAL_PTR(b, a);
      
      Some places were clean up afterwards to make syntax-check happy
      (e.g. some curly braces were removed where the body become a one
      liner).
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NErik Skultety <eskultet@redhat.com>
      5772885d
  4. 05 12月, 2018 1 次提交
  5. 20 9月, 2018 2 次提交
  6. 17 9月, 2018 1 次提交
  7. 28 5月, 2018 3 次提交
  8. 04 5月, 2018 1 次提交
    • J
      conf: Clean up object referencing for Add and Remove · b04629b6
      John Ferlan 提交于
      When adding a new object to the domain object list, there should
      have been 2 virObjectRef calls made one for each list into which
      the object was placed to match the 2 virObjectUnref calls that
      would occur during Remove as part of virHashRemoveEntry when
      virObjectFreeHashData is called when the element is removed from
      the hash table as set up in virDomainObjListNew.
      
      Some drivers (libxl, lxc, qemu, and vz) handled this inconsistency
      by calling virObjectRef upon successful return from virDomainObjListAdd
      in order to use virDomainObjEndAPI when done with the returned @vm.
      While others (bhyve, openvz, test, and vmware) handled this via only
      calling virObjectUnlock upon successful return from virDomainObjListAdd.
      
      This patch will "unify" the approach to use virDomainObjEndAPI
      for any @vm successfully returned from virDomainObjListAdd.
      
      Because list removal is so tightly coupled with list addition,
      this patch fixes the list removal algorithm to return the object
      as entered - "locked and reffed".  This way, the callers can then
      decide how to uniformly handle add/remove success and failure.
      This removes the onus on the caller to "specially handle" the
      @vm during removal processing.
      
      The Add/Remove logic allows for some logic simplification such
      as in libxl where we can Remove the @vm directly rather than
      needing to set a @remove_dom boolean and removing after the
      libxlDomainObjEndJob completes as the @vm is locked/reffed.
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      Reviewed-by: NErik Skultety <eskultet@redhat.com>
      b04629b6
  9. 23 4月, 2018 2 次提交
  10. 20 4月, 2018 2 次提交
    • J
      vz: Use virDomainObjListFindBy{UUID|ID}Ref · 3c66d510
      John Ferlan 提交于
      For vzDomainLookupByID and vzDomainLookupByUUID let's
      return a locked and referenced @vm object so that callers
      can then use the common and more consistent virDomainObjEndAPI
      in order to handle cleanup rather than needing to know that the
      returned object is locked and calling virObjectUnlock.
      
      The LookupByName already returns the ref counted and locked object,
      so this will make things more consistent.
      
      Also adjust the prlsdkHandle{VmState|VmRemoved|Perf}Event APIs
      in the same manner.
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      Reviewed-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
      3c66d510
    • J
      vz: Unify vzDomObjFromDomain{Ref} · d758374d
      John Ferlan 提交于
      Rather than have two API's doing different things for different
      callers, let's make one API that will always return a locked and
      ref counted object. That way, the callers will always know that
      they must call virDomainObjEndAPI and not have to decide whether
      they should call virObjectUnlock instead.
      
      This will make things consistent with LookupByName which returns
      the locked and ref counted object.
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      Reviewed-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
      d758374d
  11. 19 4月, 2018 1 次提交
  12. 18 4月, 2018 2 次提交
  13. 12 4月, 2018 4 次提交
  14. 16 3月, 2018 1 次提交
  15. 28 2月, 2018 1 次提交
  16. 03 11月, 2017 1 次提交
    • A
      Remove backslash alignment attempts · 3e7db8d3
      Andrea Bolognani 提交于
      Right-aligning backslashes when defining macros or using complex
      commands in Makefiles looks cute, but as soon as any changes is
      required to the code you end up with either distractingly broken
      alignment or unnecessarily big diffs where most of the changes
      are just pushing all backslashes a few characters to one side.
      
      Generated using
      
        $ git grep -El '[[:blank:]][[:blank:]]\\$' | \
          grep -E '*\.([chx]|am|mk)$$' | \
          while read f; do \
            sed -Ei 's/[[:blank:]]*[[:blank:]]\\$/ \\/g' "$f"; \
          done
      Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
      3e7db8d3
  17. 18 10月, 2017 1 次提交
  18. 14 10月, 2017 1 次提交
  19. 21 9月, 2017 1 次提交
    • J
      cpu_conf: Drop updateCPU from virCPUDefFormat · 4fd179f5
      Jiri Denemark 提交于
      In the past we updated host-model CPUs with host CPU data by adding a
      model and features, but keeping the host-model mode. And since the CPU
      model is not normally formatted for host-model CPU defs, we had to pass
      the updateCPU flag to the formatting code to be able to properly output
      updated host-model CPUs. Libvirt doesn't do this anymore, host-model
      CPUs are turned into custom mode CPUs once updated with host CPU data
      and thus there's no reason for keeping the hacks inside CPU XML
      formatters.
      Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      4fd179f5
  20. 18 9月, 2017 1 次提交
  21. 29 6月, 2017 1 次提交
  22. 25 6月, 2017 1 次提交
    • J
      events: Avoid double free possibility on remote call failure · 2065499b
      John Ferlan 提交于
      If a remote call fails during event registration (more than likely from
      a network failure or remote libvirtd restart timed just right), then when
      calling the virObjectEventStateDeregisterID we don't want to call the
      registered @freecb function because that breaks our contract that we
      would only call it after succesfully returning.  If the @freecb routine
      were called, it could result in a double free from properly coded
      applications that free their opaque data on failure to register, as seen
      in the following details:
      
          Program terminated with signal 6, Aborted.
          #0  0x00007fc45cba15d7 in raise
          #1  0x00007fc45cba2cc8 in abort
          #2  0x00007fc45cbe12f7 in __libc_message
          #3  0x00007fc45cbe86d3 in _int_free
          #4  0x00007fc45d8d292c in PyDict_Fini
          #5  0x00007fc45d94f46a in Py_Finalize
          #6  0x00007fc45d960735 in Py_Main
          #7  0x00007fc45cb8daf5 in __libc_start_main
          #8  0x0000000000400721 in _start
      
      The double dereference of 'pyobj_cbData' is triggered in the following way:
      
          (1) libvirt_virConnectDomainEventRegisterAny is invoked.
          (2) the event is successfully added to the event callback list
              (virDomainEventStateRegisterClient in
              remoteConnectDomainEventRegisterAny returns 1 which means ok).
          (3) when function remoteConnectDomainEventRegisterAny is hit,
              network connection disconnected coincidently (or libvirtd is
              restarted) in the context of function 'call' then the connection
              is lost and the function 'call' failed, the branch
              virObjectEventStateDeregisterID is therefore taken.
          (4) 'pyobj_conn' is dereferenced the 1st time in
              libvirt_virConnectDomainEventFreeFunc.
          (5) 'pyobj_cbData' (refered to pyobj_conn) is dereferenced the
               2nd time in libvirt_virConnectDomainEventRegisterAny.
          (6) the double free error is triggered.
      
      Resolve this by adding a @doFreeCb boolean in order to avoid calling the
      freeCb in virObjectEventStateDeregisterID for any remote call failure in
      a remoteConnect*EventRegister* API. For remoteConnect*EventDeregister* calls,
      the passed value would be true indicating they should run the freecb if it
      exists; whereas, it's false for the remote call failure path.
      
      Patch based on the investigation and initial patch posted by
      fangying <fangying1@huawei.com>.
      2065499b
  23. 07 6月, 2017 2 次提交
  24. 05 6月, 2017 1 次提交
  25. 24 5月, 2017 1 次提交
  26. 09 5月, 2017 1 次提交
  27. 18 4月, 2017 2 次提交
  28. 04 4月, 2017 1 次提交
  29. 03 4月, 2017 1 次提交
    • M
      virGetDomain: Set domain ID too · 5683b213
      Michal Privoznik 提交于
      So far our code is full of the following pattern:
      
        dom = virGetDomain(conn, name, uuid)
        if (dom)
            dom->id = 42;
      
      There is no reasong why it couldn't be just:
      
        dom = virGetDomain(conn, name, uuid, id);
      
      After all, client domain representation consists of tuple (name,
      uuid, id).
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      5683b213