On Wed, Jan 13, 2016 at 07:29:48AM -0500, John Ferlan wrote:
Commit id '71ce4759' altered the cgroup processing with respect to the call to virCgroupAddTask being moved out from lower layers into the calling layers especially for qemu processing of emulator and vcpu threads.What was missed in the processing was that it is possible for a code path to return a NULL cgroup *and* a 0 return status via virCgroupNewPartition failure when virCgroupNewIgnoreError succeeded when virCgroupNewMachineManual returns. This was initially seen for lxc cgroup processing and patched by comit id 'ae09988eb'. We'll make the same check here as a subsquent patch will revert commit id 'a41c00b47' which would leave the possibility that priv->cgroup is NULL. Signed-off-by: John Ferlan <jfer...@redhat.com> --- src/qemu/qemu_cgroup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/qemu/qemu_cgroup.c b/src/qemu/qemu_cgroup.c index 91b3328..515d76a 100644 --- a/src/qemu/qemu_cgroup.c +++ b/src/qemu/qemu_cgroup.c @@ -782,7 +782,7 @@ qemuInitCgroup(virQEMUDriverPtr driver, nnicindexes, nicindexes, vm->def->resource->partition, cfg->cgroupControllers, - &priv->cgroup) < 0) { + &priv->cgroup) < 0 || !priv->cgroup) { if (virCgroupNewIgnoreError())
Why don't we check for virCgroupNewIgnoreError() in LXC? If cgroups are required there, then why *does* the vircgroup code check for that? I think we should not call that function here, mainly because virCgroupNewMachine() calls that every time cgroup creation fails. Calling this second time probably doesn't hurt now, but could be potentially problematic in hypothetical future change. Anyway, I think the proper call codeflow should be: if (virCgroupNewMachine() < 0) goto cleanup; if (!priv->cgroup) goto done; It's more readable, more error-prone and so on. Same with LXC. Martin
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
