[Lxc-users] [PATCH 2/2] cgroups: support cgroups mounted in multiple places

Michael H. Warfield mhw at WittsEnd.com
Sun Jun 26 17:56:14 UTC 2011


Looking at the sources and Serge's patch...

On Sun, 2011-06-26 at 13:33 -0400, Michael H. Warfield wrote: 
> On Sun, 2011-06-26 at 18:27 +0200, Daniel Lezcano wrote: 
> > On 06/26/2011 05:52 PM, Michael H. Warfield wrote:
> > > On Sun, 2011-06-26 at 17:27 +0200, Daniel Lezcano wrote: 
> > >> On 06/26/2011 05:06 PM, Serge E. Hallyn wrote:
> > >>> Quoting Michael H. Warfield (mhw at WittsEnd.com):
> > >>>>> cd /sys/fs/cgroup
> > >>>>>    for d in `/bin/ls`; do
> > >>>>>       echo 1 > $d/cgroup.clone_children
> > >>>>>    done
> > >>>>
> > >>>> Doing this step alone broke lxc totally for me, with or without the
> > >>>> patch below.  This was on Fedora 15 testing with lxc 0.7.4.2 as well as
> > >>>
> > >>> Do you have the ns cgroup mounted?  The above is only for without
> > >>> ns cgroup.
> > > 
> > >> Yes, the ns_cgroup and clone_children are mutually exclusive.
> > > 
> > >> If you try to create a namespace with a ns cgroup mounted and the
> > >> clone_children flag is set. The 'clone' will return EINVAL.
> > > 
> > >> I noticed with the patch applied because there was a bug in it which was
> > >> setting this flag even if the cgroup was ns.
> > > 
> > >> It is possible, you ran lxc with the patch, the clone_children was set,
> > >> and then you remove the patch and try to run lxc again. As the
> > >> clone_children is still set, that will make impossible to clone a new
> > >> namespace.
> > > 
> > >> With the patch I sent previously on top of Serge's patch, that should be
> > >> fixed.
> > > 
> > > Ok...  Got that an threw it into the mix.
> > > 
> > > I'm still seeing the segfaults on lxc-info.  Seems to fault even if I
> > > specify the name of a non-existent machine as well.
> 
> > Oh, seems I missed this info :s
> 
> > If you launch lxc-info -n foo, that segfaults ?
> 
> > On what architecture does it fault ?
> 
> Fedora 15, x86_64.
> 
> 0.7.4.2 is fine.
> 
> Just rebuilt a fresh set of packages from GIT sources alone.  They're
> fine and lxc-info from git works.
> 
> Git patched with Serge's patch.  Segfault.
> 
> Git patched with both patches.  Segfault.
> 
> Here's what gdb has to say about it:
> 
> [root at forest lxc]# gdb lxc-info core.13546 
> GNU gdb (GDB) Fedora (7.2.90.20110525-39.fc15)
> Copyright (C) 2011 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-redhat-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /home/mhw/rpmbuild/BUILD/lxc-0.7.4.2git2/src/lxc/lxc-info...done.
> [New LWP 13546]
> Core was generated by `./lxc-info -n Alcove'.
> Program terminated with signal 11, Segmentation fault.
> #0  lxc_cgroup_path_get (path=0x7fff89b35928, subsystem=0x7fba52a4fdc1 "freezer", name=0x7fff89b3987d "Alcove") at cgroup.c:326
> 326	               *s = '\0';
> (gdb) trace
> Tracepoint 1 at 0x7fba52a41e74: file cgroup.c, line 326.
> (gdb) backtrace
> #0  lxc_cgroup_path_get (path=0x7fff89b35928, subsystem=0x7fba52a4fdc1 "freezer", name=0x7fff89b3987d "Alcove") at cgroup.c:326
> #1  0x00007fba52a4a337 in freezer_state (name=<optimized out>) at state.c:74
> #2  0x00007fba52a4a42d in lxc_getstate (name=0x7fff89b3987d "Alcove") at state.c:130
> #3  0x000000000040068d in main (argc=<optimized out>, argv=<optimized out>) at lxc_info.c:63

Ok...  That looks like this piece from that patch:

+/*
+ * lxc_cgroup_path_get: put into *path the pathname for
+ * %subsystem and cgroup %name.  If %subsystem is NULL, then
+ * the first mounted cgroup will be used (for nr_tasks)
+ */
+int lxc_cgroup_path_get(char **path, const char *subsystem, const char
*name)
+{
+       static char        buf[MAXPATHLEN];
+       static char        retbuf[MAXPATHLEN];
+
+       /* what lxc_cgroup_set calls subsystem is actually the filename,
i.e.
+          'devices.allow'.  So for our purposee we trim it */
+       if (subsystem) {
+               snprintf(retbuf, MAXPATHLEN, "%s", subsystem);
+               char *s = index(retbuf, '.');
+               *s = '\0';
+               DEBUG("%s: called for subsys %s name %s\n", __func__,
retbuf, name);
        }

Now wait a minute.  Is that a typo here:

char *s = index(retbuf, '.');

If you're doing, in effect, a dirname here should that be this:

char *s = index(retbuf, '/');

IAC...  That "*s = '\0';" should include a NULL check.

Adding the NULL check and lxc-info works.

Looks like that subsystem name in the call to that routine is not what
Serge thought it was.  I threw a print above the snprintf about just for
giggles to print out the subsystem name being passed to it and this is
what I got back...

[mhw at forest SPECS]$ sudo lxc-info -n Alcove
subsystem name: "freezer"
'Alcove' is RUNNING

No wonder "s" was null.  No dot and no /.


Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20110626/8cb62aa6/attachment.pgp>


More information about the lxc-users mailing list