Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

This fixes virCgroupEnableMissingControllers where virCgroupRemove
was not called in case virCgroupMakeGroup failed.
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

The case where we need path of any controller is only for internal use
so move it out to a different function.
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

The 'mntDir' is part of 'struct mntent' as a result of getmntent_r
therefore we should not mangle with it.
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Broken by commit <901d2b9c>.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

There is no need for this function, both of the checks are done
later by virCgroupGetControllerPath.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Commit <eaf2c9f8> moved machineName
generation before virCgroupNewDetectMachine() is called.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

This reverts commit 0f80c718.

Turns out, our code relies on virCgroupFree(&var) setting
var = NULL.

Conflicts:
  src/util/vircgroup.c: context because 94f1855f is not
  reverted.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

This reverts commit 4da4a9fe.

Turns out, our code relies on virCgroupFree(&var) setting
var = NULL.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

This reverts commit dd47145a.

Turns out, our code relies on virCgroupFree(&var) setting
var = NULL.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

By making use of GNU C's cleanup attribute handled by the
VIR_AUTOPTR macro for declaring aggregate pointer variables,
majority of the calls to *Free functions can be dropped, which
in turn leads to getting rid of most of our cleanup sections.
Signed-off-by: NSukrit Bhatnagar <skrtbhtngr@gmail.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

By making use of GNU C's cleanup attribute handled by the
VIR_AUTOFREE macro for declaring scalar variables, majority
of the VIR_FREE calls can be dropped, which in turn leads to
getting rid of most of our cleanup sections.
Signed-off-by: NSukrit Bhatnagar <skrtbhtngr@gmail.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Using the new VIR_DEFINE_AUTOPTR_FUNC macro defined in
src/util/viralloc.h, define a new wrapper around an existing
cleanup function which will be called when a variable declared
with VIR_AUTOPTR macro goes out of scope. Also, drop the redundant
viralloc.h include, since that has moved from the source module into
the header.

When a variable of type virCgroupPtr is declared using
VIR_AUTOPTR, the function virCgroupFree will be run
automatically on it when it goes out of scope.

This commit also adds an intermediate typedef for virCgroup
type for use with the cleanup macros.
Signed-off-by: NSukrit Bhatnagar <skrtbhtngr@gmail.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Modify virCgroupFree function signature to take a value of type
virCgroupPtr instead of virCgroupPtr * as the parameter.

Change the argument type in all calls to virCgroupFree function
from virCgroupPtr * to virCgroupPtr. This is a step towards
having consistent function signatures for Free helpers so that
they can be used with VIR_AUTOPTR cleanup macro.
Signed-off-by: NSukrit Bhatnagar <skrtbhtngr@gmail.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

This commit fixes a mount call inside virgroup.c file. The NULL value
into 'type' argument is causing a valgrind issue. See commit 794b576c
for more details. The best approach to fix it is moving NULL to "none"
filesytem.
Signed-off-by: NJulio Faracco <jcfaracco@gmail.com>

We are given a string in @machinename, we never allocate it, just
merely use it for reading. We should not free it otherwise it
leads to double free:

==32191== Thread 17:
==32191== Invalid free() / delete / delete[] / realloc()
==32191==    at 0x4C2D1A0: free (vg_replace_malloc.c:530)
==32191==    by 0x54BBB84: virFree (viralloc.c:582)
==32191==    by 0x2BC04499: qemuProcessStop (qemu_process.c:6313)
==32191==    by 0x2BC500FF: processMonitorEOFEvent (qemu_driver.c:4724)
==32191==    by 0x2BC502FC: qemuProcessEventHandler (qemu_driver.c:4769)
==32191==    by 0x5550640: virThreadPoolWorker (virthreadpool.c:167)
==32191==    by 0x554FBCF: virThreadHelper (virthread.c:206)
==32191==    by 0x8F913D3: start_thread (in /lib64/libpthread-2.23.so)
==32191==    by 0x928DE3C: clone (in /lib64/libc-2.23.so)
==32191==  Address 0x31893d70 is 0 bytes inside a block of size 1,100 free'd
==32191==    at 0x4C2D1A0: free (vg_replace_malloc.c:530)
==32191==    by 0x54BBB84: virFree (viralloc.c:582)
==32191==    by 0x54C1936: virCgroupValidateMachineGroup (vircgroup.c:343)
==32191==    by 0x54C4B29: virCgroupNewDetectMachine (vircgroup.c:1550)
==32191==    by 0x2BBDDA29: qemuConnectCgroup (qemu_cgroup.c:972)
==32191==    by 0x2BC05DA7: qemuProcessReconnect (qemu_process.c:6822)
==32191==    by 0x554FBCF: virThreadHelper (virthread.c:206)
==32191==    by 0x8F913D3: start_thread (in /lib64/libpthread-2.23.so)
==32191==    by 0x928DE3C: clone (in /lib64/libc-2.23.so)
==32191==  Block was alloc'd at
==32191==    at 0x4C2BE80: malloc (vg_replace_malloc.c:298)
==32191==    by 0x4C2E35F: realloc (vg_replace_malloc.c:785)
==32191==    by 0x54BB492: virReallocN (viralloc.c:245)
==32191==    by 0x54BEDF2: virBufferGrow (virbuffer.c:150)
==32191==    by 0x54BF3B9: virBufferVasprintf (virbuffer.c:408)
==32191==    by 0x54BF324: virBufferAsprintf (virbuffer.c:381)
==32191==    by 0x55BB271: virDomainGenerateMachineName (domain_conf.c:27078)
==32191==    by 0x2BBD5B8F: qemuDomainGetMachineName (qemu_domain.c:9595)
==32191==    by 0x2BBDD9B4: qemuConnectCgroup (qemu_cgroup.c:966)
==32191==    by 0x2BC05DA7: qemuProcessReconnect (qemu_process.c:6822)
==32191==    by 0x554FBCF: virThreadHelper (virthread.c:206)
==32191==    by 0x8F913D3: start_thread (in /lib64/libpthread-2.23.so)

Moreover, make the @machinename 'const char *' to mark it
explicitly that we are not changing the passed string.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

It is more related to a domain as we might use it even when there is
no systemd and it does not use any dbus/systemd functions.  In order
not to use code from conf/ in util/ pass machineName in cgroups code
as a parameter.  That also fixes a leak of machineName in the lxc
driver and cleans up and de-duplicates some code.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Currently the scan of the /proc/mounts file used to find cgroup mount
points doesn't take into account that mount points may hidden by other
mount points. For, example in certain Kubernetes environments the
/proc/mounts contains the following lines:

  cgroup /sys/fs/cgroup/net_prio,net_cls cgroup ...
  tmpfs /sys/fs/cgroup tmpfs ...
  cgroup /sys/fs/cgroup/net_cls,net_prio cgroup ...

In this particular environment the first mount point is hidden by the
second one. The correct mount point is the third one, but libvirt will
never process it because it only checks the first mount point for each
controller (net_cls in this case). So libvirt will try to use the first
mount point, which doesn't actually exist, and the complete detection
process will fail.

To avoid that issue this patch changes the virCgroupDetectMountsFromFile
function so that when there are duplicates it takes the information from
the last line in /proc/mounts. This requires removing the previous
explicit condition to skip duplicates, and adding code to free the
memory used by the processing of duplicated lines.

Related-To: https://bugzilla.redhat.com/1468214
Related-To: https://github.com/kubevirt/libvirt/issues/4Signed-off-by: NJuan Hernandez <jhernand@redhat.com>

Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Currently when spawning containers with systemd, the container PID 1
will get moved into the systemd machine slice. Libvirt then manually
moves the libvirt_lxc and qemu-nbd processes into the cgroups associated
with the slice, but skips the systemd controller cgroup. This means that
from systemd's POV, libvirt_lxc and qemu-nbd are still part of the
libvirtd.service unit.

On systemctl daemon-reload, it will notice that libvirt_lxc & qemu-nbd
are in the libvirtd.service unit for the systemd controller, but in the
machine cgroups for resources. Systemd will thus move them back into
the libvirtd.service resource cgroups next time libvirtd is restarted.
This causes libvirtd to kill off the container due to incorrect cgroup
placement.

The solution is to ensure that when moving libvirt_lxc & qemu-nbd, we
also move the systemd cgroup controller placement. Normally this is
not something we ever want todo, but this is a special case as we are
intentionally wanting to move them to a different systemd unit.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

This patch reduces the complexity of the filtering algorithm in
virCgroupDetect by first correcting the controller mask and then
checking for potential co-mounts without any correlating
controller mask modifications.

If you agree that this patch removes complexity and improves
readability it could simply be squashed into the first patch
of this series.
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.vnet.ibm.com>
Reviewed-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>

The cgroup controller filtering in virCgroupDetect does not work
properly if the following conditions are met:
1) the host system does not have a cgroup controller which
libvirt requests (unavailable controller) and
2) libvirt is configured to disable a controller (disabled controller) and
3) the disabled controller is located before the unavailable controller
in virCgroupController.

As an example: The memory controller is unavailable and the cpuset
controller is configured to be disabled.
In this scenario trying to start a domain results in the error
error: Controller 'cpuset' is not wanted, but 'memory' is co-mounted: Invalid argument

This error occurs when virCgroupDetect is called with a valid parent group.
The resulting group created by virCgroupCopyMounts holds for cpuset and
memory controller empty mount points. The filtering of disabled controllers
checks for co-mounts by comparing the mount points. The cpuset controller
causes the filtering to occur before the memory controller is marked as to be
ignored by modifying the controller mask since it is unavailable.
Therefore the co-mount detection logic compares the cpuset and memory controller
mount points and since both are empty the memory controller is regarded
erroneously as being co-mounted.
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.vnet.ibm.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

With kernel 3.18 (since commit 3e32cb2e0a12b6915056ff04601cf1bb9b44f967)
the "unlimited" value for cgroup memory limits has changed once again as
its byte value is now computed from a page counter.
The new "unlimited" value reported by the cgroup fs is therefore 2**51-1
pages which is (VIR_DOMAIN_MEMORY_PARAM_UNLIMITED - 3072). This results
e.g. in virsh memtune displaying 9007199254740988 instead of unlimited
for the limits.

This patch uses the value of memory.limit_in_bytes from the cgroup
memory root which is the system's "real" unlimited value for comparison.

See also libvirt commit 231656bb for the
history for kernel 3.12 and before.
Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>

We have couple of functions that operate over NULL terminated
lits of strings. However, our naming sucks:

virStringJoin
virStringFreeList
virStringFreeListCount
virStringArrayHasString
virStringGetFirstWithPrefix

We can do better:

virStringListJoin
virStringListFree
virStringListFreeCount
virStringListHasString
virStringListGetFirstWithPrefix
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>