[libvirt] [PATCH 5/6] qemu: Leave cpuset.mems in parent cgroup alone

Martin Kletzander mkletzan at redhat.com
Wed Dec 17 15:06:40 UTC 2014


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 at redhat.com>
>>> ---
>>>  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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20141217/7f8d0d65/attachment-0001.sig>


More information about the libvir-list mailing list