On Wed, Dec 17, 2014 at 12:00:36AM -0700, Eric Blake wrote:
On 12/16/2014 11:51 PM, Eric Blake wrote:On 12/15/2014 12:58 AM, Martin Kletzander wrote:Instead of setting the value of cpuset.mems once when the domain starts and then re-calculating the value every time we need to change the child cgroup values, leave the cgroup alone and rather set the child data every time there is new cgroup created. We don't leave any task in the parent group anyway. This will ease both current and future code. Signed-off-by: Martin Kletzander <mkletzan@xxxxxxxxxx> --- src/qemu/qemu_cgroup.c | 67 ++++++++++++++++++++++++++++++++++++++++++++++++-- src/qemu/qemu_driver.c | 59 +++++++++++++++----------------------------- 2 files changed, 85 insertions(+), 41 deletions(-)This patch causes libvirtd to segfault on startup:More particularly, I'm doing an upgrade from older libvirtd to this version, while leaving a transient domain running that was started by the older libvirtd. Hope that helps you narrow in on the problem.
I tried that and it works for me. And I tried various domains, both heavily cgroup dependent and simple ones.
Reverting 86759e and af2a1f0 was sufficient to get me going again locally, but I'm not going to push my reversions until you've first had a chance to address the regression.Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffda116700 (LWP 15311)] 0x00007ffff7400890 in virCgroupPathOfController (group=0x0, controller=2, key=0x7ffff768a019 "tasks", path=0x7fffda115b30) at util/vircgroup.c:1867 1867 if (group->controllers[controller].mountPoint == NULL) { (gdb) bt #0 0x00007ffff7400890 in virCgroupPathOfController (group=0x0, controller=2, key=0x7ffff768a019 "tasks", path=0x7fffda115b30) at util/vircgroup.c:1867 #1 0x00007ffff73fe4db in virCgroupGetValueStr (group=0x0, controller=2, key=0x7ffff768a019 "tasks", value=0x7fffda115b80) at util/vircgroup.c:751 #2 0x00007ffff7405673 in virCgroupHasEmptyTasks (cgroup=0x0, controller=2) at util/vircgroup.c:3935
From this line it looks like priv->cgroup was not initialized. I did not add a check for that, so that may be the cause. I'll send a patch soon. But I wonder how did you manage to do that, is that a session libvirtd you restarted? Otherwise how come virCgroupNewDetectMachine() didn't fill the cgroup?
#3 0x00007fffdc79c687 in qemuRestoreCgroupState (vm=0x7fffd41dd8d0) at qemu/qemu_cgroup.c:802 #4 0x00007fffdc79c80c in qemuConnectCgroup (driver=0x7fffd4152ae0, vm=0x7fffd41dd8d0) at qemu/qemu_cgroup.c:848 #5 0x00007fffdc7b8553 in qemuProcessReconnect (opaque=0x7fffd41da150) at qemu/qemu_process.c:3616 #6 0x00007ffff7469830 in virThreadHelper (data=0x7fffd41c5b00) at util/virthread.c:197 #7 0x00007ffff3e65ee5 in start_thread (arg=0x7fffda116700) at pthread_create.c:309 #8 0x00007ffff3b94b8d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111-- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list