1. 29 4月, 2008 15 次提交
  2. 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
  3. 11 4月, 2008 1 次提交
  4. 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
  5. 31 3月, 2008 1 次提交
  6. 05 3月, 2008 1 次提交
  7. 24 2月, 2008 5 次提交
  8. 08 2月, 2008 9 次提交
  9. 15 11月, 2007 1 次提交
  10. 24 10月, 2007 1 次提交
  11. 20 10月, 2007 4 次提交
    • P
      Control groups: Replace "cont" with "cgrp" and other misc renaming · bd89aabc
      Paul Menage 提交于
      Replace "cont" with "cgrp" and other misc renaming
      
      This patch finishes some of the names that got missed in the great
      "task containers" -> "control groups" rename. Primarily it renames
      the local variable "cont" to "cgrp" in a number of places, and renames
      the CONT_* enum members to CGRP_*.
      
      This patch is not intended to have any effect on the generated code;
      the output of "objdump -d kernel/cgroup.o" is unchanged.
      Signed-off-by: NPaul Menage <menage@google.com>
      Acked-by: NPaul Jackson <pj@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      bd89aabc
    • P
      Use task_pid_nr() instead of pid_nr(task_pid()) · 69cccb88
      Pavel Emelyanov 提交于
      There are two places that do so - the cgroups subsystem and the autofs
      code.
      Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
      Cc: Ian Kent <raven@themaw.net>
      Cc: Paul Menage <menage@google.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      69cccb88
    • B
      Add cgroupstats · 846c7bb0
      Balbir Singh 提交于
      This patch is inspired by the discussion at
      http://lkml.org/lkml/2007/4/11/187 and implements per cgroup statistics
      as suggested by Andrew Morton in http://lkml.org/lkml/2007/4/11/263.  The
      patch is on top of 2.6.21-mm1 with Paul's cgroups v9 patches (forward
      ported)
      
      This patch implements per cgroup statistics infrastructure and re-uses
      code from the taskstats interface.  A new set of cgroup operations are
      registered with commands and attributes.  It should be very easy to
      *extend* per cgroup statistics, by adding members to the cgroupstats
      structure.
      
      The current model for cgroupstats is a pull, a push model (to post
      statistics on interesting events), should be very easy to add.  Currently
      user space requests for statistics by passing the cgroup file
      descriptor.  Statistics about the state of all the tasks in the cgroup
      is returned to user space.
      
      TODO's/NOTE:
      
      This patch provides an infrastructure for implementing cgroup statistics.
      Based on the needs of each controller, we can incrementally add more statistics,
      event based support for notification of statistics, accumulation of taskstats
      into cgroup statistics in the future.
      
      Sample output
      
      # ./cgroupstats -C /cgroup/a
      sleeping 2, blocked 0, running 1, stopped 0, uninterruptible 0
      
      # ./cgroupstats -C /cgroup/
      sleeping 154, blocked 0, running 0, stopped 0, uninterruptible 0
      
      If the approach looks good, I'll enhance and post the user space utility for
      the same
      
      Feedback, comments, test results are always welcome!
      
      [akpm@linux-foundation.org: build fix]
      Signed-off-by: NBalbir Singh <balbir@linux.vnet.ibm.com>
      Cc: Paul Menage <menage@google.com>
      Cc: Jay Lan <jlan@engr.sgi.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      846c7bb0
    • P
      Task Control Groups: automatic userspace notification of idle cgroups · 81a6a5cd
      Paul Menage 提交于
      Add the following files to the cgroup filesystem:
      
      notify_on_release - configures/reports whether the cgroup subsystem should
      attempt to run a release script when this cgroup becomes unused
      
      release_agent - configures/reports the release agent to be used for this
      hierarchy (top level in each hierarchy only)
      
      releasable - reports whether this cgroup would have been auto-released if
      notify_on_release was true and a release agent was configured (mainly useful
      for debugging)
      
      To avoid locking issues, invoking the userspace release agent is done via a
      workqueue task; cgroups that need to have their release agents invoked by
      the workqueue task are linked on to a list.
      
      [pj@sgi.com: Need to include kmod.h]
      Signed-off-by: NPaul Menage <menage@google.com>
      Cc: Serge E. Hallyn <serue@us.ibm.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Dave Hansen <haveblue@us.ibm.com>
      Cc: Balbir Singh <balbir@in.ibm.com>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Kirill Korotaev <dev@openvz.org>
      Cc: Herbert Poetzl <herbert@13thfloor.at>
      Cc: Srivatsa Vaddagiri <vatsa@in.ibm.com>
      Cc: Cedric Le Goater <clg@fr.ibm.com>
      Signed-off-by: NPaul Jackson <pj@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      81a6a5cd