1. 26 7月, 2008 6 次提交
  2. 25 5月, 2008 1 次提交
    • C
      cgroups: remove node_ prefix_from ns subsystem · 5c02b575
      Cedric Le Goater 提交于
      This is a slight change in the namespace cgroup subsystem api.
      
      The change is that previously when cgroup_clone() was called (currently
      only from the unshare path in ns_proxy cgroup, you'd get a new group named
      "node_$pid" whereas now you'll get a group named after just your pid.)
      
      The only users who would notice it are those who are using the ns_proxy
      cgroup subsystem to auto-create cgroups when namespaces are unshared -
      something of an experimental feature, which I think really needs more
      complete container/namespace support in order to be useful.  I suspect the
      only users are Cedric and Serge, or maybe a few others on
      containers@lists.linux-foundation.org.  And in fact it would only be
      noticed by the users who make the assumption about how the name is
      generated, rather than getting it from the /proc/<pid>/cgroups file for
      the process in question.
      
      Whether the change is actually needed or not I'm fairly agnostic on, but I
      guess it is more elegant to just use the pid as the new group name rather
      than adding a fairly arbitrary "node_" prefix on the front.
      
      [menage@google.com: provided changelog]
      Signed-off-by: NCedric Le Goater <clg@fr.ibm.com>
      Cc: "Paul Menage" <menage@google.com>
      Cc: "Serge E. Hallyn" <serue@us.ibm.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5c02b575
  3. 30 4月, 2008 1 次提交
  4. 29 4月, 2008 15 次提交
  5. 18 4月, 2008 1 次提交
    • L
      cgroup: fix a race condition in manipulating tsk->cg_list · 0e04388f
      Li Zefan 提交于
      When I ran a test program to fork mass processes and at the same time
      'cat /cgroup/tasks', I got the following oops:
      
        ------------[ cut here ]------------
        kernel BUG at lib/list_debug.c:72!
        invalid opcode: 0000 [#1] SMP
        Pid: 4178, comm: a.out Not tainted (2.6.25-rc9 #72)
        ...
        Call Trace:
         [<c044a5f9>] ? cgroup_exit+0x55/0x94
         [<c0427acf>] ? do_exit+0x217/0x5ba
         [<c0427ed7>] ? do_group_exit+0.65/0x7c
         [<c0427efd>] ? sys_exit_group+0xf/0x11
         [<c0404842>] ? syscall_call+0x7/0xb
         [<c05e0000>] ? init_cyrix+0x2fa/0x479
        ...
        EIP: [<c04df671>] list_del+0x35/0x53 SS:ESP 0068:ebc7df4
        ---[ end trace caffb7332252612b ]---
        Fixing recursive fault but reboot is needed!
      
      After digging into the code and debugging, I finlly found out a race
      situation:
      
      				do_exit()
      				  ->cgroup_exit()
      				    ->if (!list_empty(&tsk->cg_list))
      				        list_del(&tsk->cg_list);
      
        cgroup_iter_start()
          ->cgroup_enable_task_cg_list()
            ->list_add(&tsk->cg_list, ..);
      
      In this case the list won't be deleted though the process has exited.
      
      We got two bug reports in the past, which seem to be the same bug as
      this one:
      	http://lkml.org/lkml/2008/3/5/332
      	http://lkml.org/lkml/2007/10/17/224
      
      Actually sometimes I got oops on list_del, sometimes oops on list_add.
      And I can change my test program a bit to trigger other oops.
      
      The patch has been tested both on x86_32 and x86_64.
      Signed-off-by: NLi Zefan <lizf@cn.fujitsu.com>
      Acked-by: NPaul Menage <menage@google.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: stable@kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0e04388f
  6. 11 4月, 2008 1 次提交
  7. 05 4月, 2008 1 次提交
    • P
      cgroups: add cgroup support for enabling controllers at boot time · 8bab8dde
      Paul Menage 提交于
      The effects of cgroup_disable=foo are:
      
      - foo isn't auto-mounted if you mount all cgroups in a single hierarchy
      - foo isn't visible as an individually mountable subsystem
      
      As a result there will only ever be one call to foo->create(), at init time;
      all processes will stay in this group, and the group will never be mounted on
      a visible hierarchy.  Any additional effects (e.g.  not allocating metadata)
      are up to the foo subsystem.
      
      This doesn't handle early_init subsystems (their "disabled" bit isn't set be,
      but it could easily be extended to do so if any of the early_init systems
      wanted it - I think it would just involve some nastier parameter processing
      since it would occur before the command-line argument parser had been run.
      
      Hugh said:
      
        Ballpark figures, I'm trying to get this question out rather than
        processing the exact numbers: CONFIG_CGROUP_MEM_RES_CTLR adds 15% overhead
        to the affected paths, booting with cgroup_disable=memory cuts that back to
        1% overhead (due to slightly bigger struct page).
      
        I'm no expert on distros, they may have no interest whatever in
        CONFIG_CGROUP_MEM_RES_CTLR=y; and the rest of us can easily build with or
        without it, or apply the cgroup_disable=memory patches.
      
      Unix bench's execl test result on x86_64 was
      
      == just after boot without mounting any cgroup fs.==
      mem_cgorup=off : Execl Throughput       43.0     3150.1      732.6
      mem_cgroup=on  : Execl Throughput       43.0     2932.6      682.0
      ==
      
      [lizf@cn.fujitsu.com: fix boot option parsing]
      Signed-off-by: NBalbir Singh <balbir@linux.vnet.ibm.com>
      Cc: Paul Menage <menage@google.com>
      Cc: Balbir Singh <balbir@linux.vnet.ibm.com>
      Cc: Pavel Emelyanov <xemul@openvz.org>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Hugh Dickins <hugh@veritas.com>
      Cc: Sudhir Kumar <skumar@linux.vnet.ibm.com>
      Cc: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
      Cc: David Rientjes <rientjes@google.com>
      Signed-off-by: NLi Zefan <lizf@cn.fujitsu.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8bab8dde
  8. 31 3月, 2008 1 次提交
  9. 05 3月, 2008 1 次提交
  10. 24 2月, 2008 5 次提交
  11. 08 2月, 2008 7 次提交