1. 12 9月, 2013 1 次提交
  2. 11 9月, 2013 1 次提交
    • D
      Fix cgroups when all are mounted on /sys/fs/cgroup · f0b6d8d4
      Daniel P. Berrange 提交于
      Some users in Ubuntu/Debian seem to have a setup where all the
      cgroup controllers are mounted on /sys/fs/cgroup rather than
      any /sys/fs/cgroup/<controller> name. In the loop which detects
      which controllers are present for a mount point we were modifying
      'mnt_dir' field in the 'struct mntent' var, but not always restoring
      the original value. This caused detection to break in the all-in-one
      mount setup.
      
      Fix that logic bug and add test case coverage for this mount
      setup.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      f0b6d8d4
  3. 13 8月, 2013 8 次提交
  4. 01 8月, 2013 3 次提交
    • D
      Enable support for systemd-machined in cgroups creation · 2fe24701
      Daniel P. Berrange 提交于
      Make the virCgroupNewMachine method try to use systemd-machined
      first. If that fails, then fallback to using the traditional
      cgroup setup code path.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      2fe24701
    • D
      Cope with races while killing processes · 75304eaa
      Daniel P. Berrange 提交于
      When systemd is involved in managing processes, it may start
      killing off & tearing down croups associated with the process
      while we're still doing virCgroupKillPainfully. We must
      explicitly check for ENOENT and treat it as if we had finished
      killing processes
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      75304eaa
    • D
      Add support for systemd cgroup mount · aedd46e7
      Daniel P. Berrange 提交于
      Systemd uses a named cgroup mount for tracking processes. Add
      it as another type of controller, albeit one which we have to
      special case in a number of places. In particular we must
      never create/delete directories there, nor add tasks. Essentially
      the systemd mount is to be considered read-only for libvirt.
      
      With this change both the virCgroupDetectPlacement and
      virCgroupCopyPlacement methods must be invoked. The copy
      placement method will copy setup for resource controllers
      only. The detect placement method will probe for any
      named controllers, or resource controllers not already
      setup.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      aedd46e7
  5. 29 7月, 2013 2 次提交
  6. 26 7月, 2013 5 次提交
  7. 25 7月, 2013 2 次提交
  8. 24 7月, 2013 4 次提交
  9. 22 7月, 2013 3 次提交
  10. 17 7月, 2013 1 次提交
    • J
      cgroup: reuse buffer for getline · cc732931
      Ján Tomko 提交于
      Reuse the buffer for getline and track buffer allocation
      separately from the string length to prevent unlikely
      out-of-bounds memory access.
      
      This fixes the following leak that happened when zero bytes were read:
      
      ==404== 120 bytes in 1 blocks are definitely lost in loss record 1,344 of 1,671
      ==404==    at 0x4C2C71B: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
      ==404==    by 0x906F862: getdelim (iogetdelim.c:68)
      ==404==    by 0x52A48FB: virCgroupPartitionNeedsEscaping (vircgroup.c:1136)
      ==404==    by 0x52A0FB4: virCgroupPartitionEscape (vircgroup.c:1171)
      ==404==    by 0x52A0EA4: virCgroupNewDomainPartition (vircgroup.c:1450)
      cc732931
  11. 11 7月, 2013 1 次提交
  12. 10 7月, 2013 2 次提交
  13. 03 7月, 2013 1 次提交
  14. 26 6月, 2013 2 次提交
    • J
      Plug leak in virCgroupMoveTask · 5bc8ecb8
      Ján Tomko 提交于
      We only break out of the while loop if *content is an empty string.
      However the buffer has been allocated to BUFSIZ + 1 (8193 in my case),
      but it gets overwritten in the next for iteration.
      
      Move VIR_FREE right before we overwrite it to avoid the leak.
      
      ==5777== 16,386 bytes in 2 blocks are definitely lost in loss record 1,022 of 1,027
      ==5777==    by 0x5296E28: virReallocN (viralloc.c:184)
      ==5777==    by 0x52B0C66: virFileReadLimFD (virfile.c:1137)
      ==5777==    by 0x52B0E1A: virFileReadAll (virfile.c:1199)
      ==5777==    by 0x529B092: virCgroupGetValueStr (vircgroup.c:534)
      ==5777==    by 0x529AF64: virCgroupMoveTask (vircgroup.c:1079)
      
      Introduced by 83e4c775.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=978352
      5bc8ecb8
    • J
      Fix invalid read in virCgroupGetValueStr · 306c49ff
      Ján Tomko 提交于
      Don't check for '\n' at the end of file if zero bytes were read.
      
      Found by valgrind:
      ==404== Invalid read of size 1
      ==404==    at 0x529B09F: virCgroupGetValueStr (vircgroup.c:540)
      ==404==    by 0x529AF64: virCgroupMoveTask (vircgroup.c:1079)
      ==404==    by 0x1EB475: qemuSetupCgroupForEmulator (qemu_cgroup.c:1061)
      ==404==    by 0x1D9489: qemuProcessStart (qemu_process.c:3801)
      ==404==    by 0x18557E: qemuDomainObjStart (qemu_driver.c:5787)
      ==404==    by 0x190FA4: qemuDomainCreateWithFlags (qemu_driver.c:5839)
      
      Introduced by 0d0b4098.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=978356
      306c49ff
  15. 06 6月, 2013 1 次提交
  16. 24 5月, 2013 3 次提交
    • V
      cgroups: Do not enforce nonexistent controllers · eb21408f
      Viktor Mihajlovski 提交于
      Currently, the controllers argument to virCgroupDetect acts both as
      a result filter and a required controller specification, which is
      a bit overloaded. If both functionalities are needed, it would be
      better to have them seperated into a filter and a requirement mask.
      The only situation where it is used today is to ensure that only
      CPU related controllers are used for the VCPU directories. But here
      we clearly do not want to enforce the existence of cpu, cpuacct and
      specifically not cpuset at the same time.
      This commit changes the semantics of controllers to "filter only".
      Should a required mask ever be needed, more work will have to be done.
      Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
      eb21408f
    • M
      Adapt to VIR_STRDUP and VIR_STRNDUP in src/util/vircgroup.c · eb8e5e87
      Michal Privoznik 提交于
      This commit is separate due to unusual paradigm compared to the
      most source files.
      eb8e5e87
    • M
      virCgroupAddTaskStrController: s/-1/-ENOMEM/ · b43bb98a
      Michal Privoznik 提交于
      Within whole vircgroup.c we 'return -errno', e.g. 'return -ENOMEM'.
      However, in this specific function virCgroupAddTaskStrController
      we weren't returning -ENOMEM but -1 despite fact that later in
      the function we are returning one of errno values indeed.
      b43bb98a