1. 25 4月, 2019 3 次提交
    • P
      util: hash: Append to hash buckets when adding new entries · 4b99ba98
      Peter Krempa 提交于
      In cases when the hash function for a name collides with other entry
      already in the hash we prepend to the bucket. This creates a 'stack
      effect' on the buckets if we then iterate through the hash. Normally
      this is not a problem, but in tests we want deterministic results.
      
      Since it does not matter where we add the entry and it's usually more
      probable that a different entry will be accessed next change it to
      append to the end of the bucket. Luckily we already iterate throught the
      bucket once thus we can easily find the last entry and just connect the
      new entry after it.
      Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      4b99ba98
    • P
      vircgroup: no need to ifdef virCgroupFree · 9470815d
      Pavel Hrdina 提交于
      virCgroup struct is always defined and the free function is not calling
      anything that would require OS supporting cgroups.
      
      This fixes an issue if we try to start a VM with QEMU binary that
      doesn't support QXL.  The start operation will fail in
      qemuProcessStartValidateVideo() which will set correct error message,
      but later in one of the cleanup paths we will call
      qemuDomainObjPrivateDataClear() which always calls virCgroupFree()
      and that will fail on OS that doesn't support cgroups and it will
      set a new error which will be eventually reported to user.
      Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
      9470815d
    • A
      Handle copying bitmaps to larger data buffers · 51f9f80d
      Allen, John 提交于
      If a bitmap of a shorter length than the data buffer is passed to
      virBitmapToDataBuf, it will read off the end of the bitmap and copy junk
      into the returned buffer. Add a check to only copy the length of the
      bitmap to the buffer.
      
      The problem can be observed after setting a vcpu affinity using the vcpupin
      command on a system with a large number of cores:
        # virsh vcpupin example_domain 0 0
        # virsh vcpupin example_domain 0
           VCPU   CPU Affinity
          ---------------------------
           0      0,192,197-198,202
      Signed-off-by: NJohn Allen <john.allen@amd.com>
      51f9f80d
  2. 17 4月, 2019 1 次提交
  3. 16 4月, 2019 3 次提交
  4. 15 4月, 2019 3 次提交
  5. 13 4月, 2019 1 次提交
  6. 12 4月, 2019 4 次提交
    • A
      maint: Add filetype annotations to Makefile.inc.am · 03a07357
      Andrea Bolognani 提交于
      Vim has trouble figuring out the filetype automatically because
      the name doesn't follow existing conventions; annotations like
      the ones we already have in Makefile.ci help it out.
      Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      03a07357
    • M
      lib: Don't use virReportSystemError() if virCommandRun() fails · 51f17c98
      Michal Privoznik 提交于
      Firstly, virCommandRun() does report an error on failure (which
      in most cases is more accurate than what we overwrite it with).
      Secondly, usually errno is not set (or gets overwritten in the
      cleanup code) which makes virReportSystemError() report useless
      error messages. Drop all virReportSystemError() calls in cases
      like this (I've found three occurrences).
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      51f17c98
    • P
      virresctrl: fix MBA memory leak · e3c4befe
      Pavel Hrdina 提交于
      The 'bandwidths' variable is allocated using VIR_RESIZE_N so it has to
      be freed as well.
      
      ==118315== 8 bytes in 1 blocks are definitely lost in loss record 299 of 2,401
      ==118315==    at 0x4C29DAD: malloc (vg_replace_malloc.c:308)
      ==118315==    by 0x4C2C100: realloc (vg_replace_malloc.c:836)
      ==118315==    by 0x52C3FAF: virReallocN (viralloc.c:245)
      ==118315==    by 0x52C4079: virExpandN (viralloc.c:294)
      ==118315==    by 0x532BBA8: virResctrlAllocParseProcessMemoryBandwidth (virresctrl.c:1156)
      ==118315==    by 0x532BBA8: virResctrlAllocParseMemoryBandwidthLine (virresctrl.c:1211)
      ==118315==    by 0x532BBA8: virResctrlAllocParse (virresctrl.c:1414)
      ==118315==    by 0x532BBA8: virResctrlAllocGetGroup (virresctrl.c:1446)
      ==118315==    by 0x532C11D: virResctrlAllocGetDefault (virresctrl.c:1464)
      ==118315==    by 0x532D15E: virResctrlAllocAssign (virresctrl.c:1923)
      ==118315==    by 0x532D15E: virResctrlAllocCreate (virresctrl.c:2042)
      ==118315==    by 0x31E1ABEE: qemuProcessResctrlCreate (qemu_process.c:2596)
      ==118315==    by 0x31E1ABEE: qemuProcessLaunch (qemu_process.c:6444)
      ==118315==    by 0x31E1E341: qemuProcessStart (qemu_process.c:6721)
      ==118315==    by 0x31E81315: qemuDomainObjStart.constprop.50 (qemu_driver.c:7288)
      ==118315==    by 0x31E81A65: qemuDomainCreateWithFlags (qemu_driver.c:7341)
      ==118315==    by 0x54DDB4B: virDomainCreate (libvirt-domain.c:6534)
      Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
      e3c4befe
    • C
      Always put _LAST enums on second line of VIR_ENUM_IMPL · 1d31526b
      Cole Robinson 提交于
      Standardize on putting the _LAST enum value on the second line
      of VIR_ENUM_IMPL invocations. Later patches that add string labels
      to VIR_ENUM_IMPL will push most of these to the second line anyways,
      so this saves some noise.
      Signed-off-by: NCole Robinson <crobinso@redhat.com>
      1d31526b
  7. 10 4月, 2019 7 次提交
  8. 09 4月, 2019 1 次提交
  9. 06 4月, 2019 1 次提交
  10. 05 4月, 2019 1 次提交
  11. 03 4月, 2019 12 次提交
  12. 28 3月, 2019 1 次提交
  13. 27 3月, 2019 1 次提交
  14. 20 3月, 2019 1 次提交