* Peter Zijlstra <pet...@infradead.org> [2011-02-07 17:10:33]:
> On Thu, 2011-02-03 at 00:32 +0530, Balbir Singh wrote:
> > > No, just fixed. The callback as it exists isn't useful and leads to
> > > hacks like the above.
>
> ---
> Subject: cgroup: Fix cgroup_subsys::exit callback
> From: Peter Zijlstra <a.p.zijls...@chello.nl>
> Date: Mon Feb 07 17:02:20 CET 2011
>
> Make the ::exit method act like ::attach, it is after all very nearly
> the same thing.
>
> Signed-off-by: Peter Zijlstra <a.p.zijls...@chello.nl>
> LKML-Reference: <new-submission>
> ---
> Index: linux-2.6/include/linux/cgroup.h
> ===================================================================
> --- linux-2.6.orig/include/linux/cgroup.h
> +++ linux-2.6/include/linux/cgroup.h
> @@ -474,7 +474,8 @@ struct cgroup_subsys {
> struct cgroup *old_cgrp, struct task_struct *tsk,
> bool threadgroup);
> void (*fork)(struct cgroup_subsys *ss, struct task_struct *task);
> - void (*exit)(struct cgroup_subsys *ss, struct task_struct *task);
> + void (*exit)(struct cgroup_subsys *ss, struct cgroup *cgrp,
> + struct cgroup *old_cgrp, struct task_struct *task);
The effective change I see
1. mutex_lock() being held
2. Old cgroup being passed as a part of the notification
Is 1 required? I don't see anything in the changelog. For (2), I don't
see it being used, is the use in the scheduler cgroup path/patch?
--
Three Cheers,
Balbir
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
