(just came back from vacation)
>> How about if the exit callback was moved before the preceding
>> task_unlock()? Since I think the scheduler is still the only user of
>> the exit callback, redefining the locking semantics should be fine.
>
> Like the below? Both the perf and sched exit callback are fine with
> being called under task_lock afaict, but I haven't actually ran with
> lockdep enabled to see if I missed something.
>
This change should be fine.
...
> +
> + if (run_callbacks && need_forkexit_callback) {
> + /*
> + * modular subsystems can't use callbacks, so no need to lock
> + * the subsys array
> + */
> + for (i = 0; i < CGROUP_BUILTIN_SUBSYS_COUNT; i++) {
> + struct cgroup_subsys *ss = subsys[i];
> + if (ss->exit) {
> + struct cgroup *old_cgrp =
> +
> rcu_dereference_raw(cg->subsys[i])->cgroup;
> + struct cgroup *cgrp = task_cgroup(tsk, i);
> + ss->exit(ss, cgrp, old_cgrp, tsk);
Since both sched and perf won't use the 2 args @cgrp and @old_cgrp,
don't bother to change the ->exit interface?
> + }
> + }
> + }
> task_unlock(tsk);
> +
> if (cg)
> put_css_set_taskexit(cg);
> }
------------------------------------------------------------------------------
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
