1. 19 Dec, 2013 2 commits
    • remove static_lock()/static_unlock() and start to use thread local storage (v2) · 95b422fc
      S.Çağlar Onur authored
      While testing https://github.com/lxc/lxc/pull/106, I found that concurrent starts
      are hanging time to time. I then reproduced the same problem in master and got following;
      
       [caglar@oOo:~] sudo gdb -p 16221
       (gdb) bt
       #0  __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
       #1  0x00007f495526515c in _L_lock_982 () from /lib/x86_64-linux-gnu/libpthread.so.0
       #2  0x00007f4955264fab in __GI___pthread_mutex_lock (mutex=0x7f49556d4600 <static_mutex>) at pthread_mutex_lock.c:64
       #3  0x00007f49554b27a6 in lock_mutex (l=l@entry=0x7f49556d4600 <static_mutex>) at lxclock.c:78
       #4  0x00007f49554b2dac in static_lock () at lxclock.c:330
       #5  0x00007f4955498f71 in lxc_global_config_value (option_name=option_name@entry=0x7f49554c02cf "cgroup.use") at utils.c:273
       #6  0x00007f495549926c in default_cgroup_use () at utils.c:366
       #7  0x00007f49554953bd in lxc_cgroup_load_meta () at cgroup.c:94
       #8  0x00007f495548debc in lxc_spawn (handler=handler@entry=0x7f49200af300) at start.c:783
       #9  0x00007f495548e7a7 in __lxc_start (name=name@entry=0x7f49200b48a0 "lxc-test-concurrent-4", conf=conf@entry=0x7f49200b2030, ops=ops@entry=0x7f49556d3900 <start_ops>, data=data@entry=0x7f495487db90,
          lxcpath=lxcpath@entry=0x7f49200b2010 "/var/lib/lxc") at start.c:951
       #10 0x00007f495548eb9c in lxc_start (name=0x7f49200b48a0 "lxc-test-concurrent-4", argv=argv@entry=0x7f495487dbe0, conf=conf@entry=0x7f49200b2030, lxcpath=0x7f49200b2010 "/var/lib/lxc") at start.c:1048
       #11 0x00007f49554b68f1 in lxcapi_start (c=0x7f49200b1dd0, useinit=<optimized out>, argv=0x7f495487dbe0) at lxccontainer.c:648
       #12 0x0000000000401317 in do_function (arguments=0x1aa80b0) at concurrent.c:94
       #13 0x0000000000401499 in concurrent (arguments=<optimized out>) at concurrent.c:130
       #14 0x00007f4955262f6e in start_thread (arg=0x7f495487e700) at pthread_create.c:311
       #15 0x00007f4954f8d9cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113
      
      It looks like both parent and child end up with locked mutex thus deadlocks.
      
      I ended up placing values in the thread local storage pool, instead of doing "unlock the lock in the child" dance
      Signed-off-by: 's avatarS.Çağlar Onur <caglar@10ur.org>
      Acked-by: 's avatarSerge E. Hallyn <serge.hallyn@ubuntu.com>
    • sshd: Don't bind-mount /sbin/init read-write · f4d5cc8e
      Stéphane Graber authored
      lxc-sshd was mounting itself (the template script) as /sbin/init in the
      container using a writable bind-mount.
      
      This shouldn't be needed and could lead to quite a few problems should
      one of those containers overwrite /sbin/init for some reason.
      
      Instead simply move to a read-only bind-mount which should prevent any
      accidental dammage.
      Signed-off-by: 's avatarStéphane Graber <stgraber@ubuntu.com>
  2. 18 Dec, 2013 1 commit
  3. 17 Dec, 2013 8 commits
  4. 16 Dec, 2013 3 commits
  5. 13 Dec, 2013 5 commits
  6. 12 Dec, 2013 11 commits
  7. 11 Dec, 2013 5 commits
  8. 10 Dec, 2013 3 commits
  9. 09 Dec, 2013 2 commits