Re: [tip:perfcounters/core] perf_counter: Fix counter inheritance

[Ingo Molnar <mingo@elte.hu>]

* tip-bot for Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:

> Commit-ID:  856d56b9e5de650a64a6c41c17aaed702b55d578
> Gitweb:     http://git.kernel.org/tip/856d56b9e5de650a64a6c41c17aaed702b55d578
> Author:     Peter Zijlstra <a.p.zijlstra@chello.nl>
> AuthorDate: Fri, 15 May 2009 20:45:59 +0200
> Committer:  Ingo Molnar <mingo@elte.hu>
> CommitDate: Sun, 17 May 2009 07:52:24 +0200
> 
> perf_counter: Fix counter inheritance
> 
> Srivatsa Vaddagiri reported that a Java workload triggers this
> warning in kernel/exit.c:
> 
>    WARN_ON_ONCE(!list_empty(&tsk->perf_counter_ctx.counter_list));
> 
> Add the inherited counter propagation on self-detach, this could
> cause counter leaks and incomplete stats in threaded code like
> the below:
> 
>   #include <pthread.h>
>   #include <unistd.h>
> 
>   void *thread(void *arg)
>   {
>           sleep(5);
>           return NULL;
>   }
> 
>   void main(void)
>   {
>           pthread_t thr;
>           pthread_create(&thr, NULL, thread, NULL);
>   }
> 
> Reported-by: Srivatsa Vaddagiri <vatsa@in.ibm.com>
> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
> Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
> Cc: Marcelo Tosatti <mtosatti@redhat.com>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> 
> 
> ---
>  kernel/exit.c |    6 ++++++
>  1 files changed, 6 insertions(+), 0 deletions(-)
> 
> diff --git a/kernel/exit.c b/kernel/exit.c
> index 4741376..16d74f1 100644
> --- a/kernel/exit.c
> +++ b/kernel/exit.c
> @@ -128,6 +128,12 @@ static void __exit_signal(struct task_struct *tsk)
>  		sig = NULL; /* Marker for below. */
>  	}
>  
> +	/*
> +	 * Flush inherited counters to the parent - before the parent
> +	 * gets woken up by child-exit notifications.
> +	 */
> +	perf_counter_exit_task(tsk);

Causes:

[  447.882292] BUG: sleeping function called from invalid context at kernel/mutex.c:94
[  447.890094] in_atomic(): 0, irqs_disabled(): 1, pid: 23597, name: hackbench_pth
[  447.897587] Pid: 23597, comm: hackbench_pth Not tainted 2.6.30-rc6-tip #188
[  447.904678] Call Trace:
[  447.907158]  [<ffffffff814cdd0b>] ? mutex_lock+0x15/0x37
[  447.912518]  [<ffffffff8108f1e3>] ? perf_counter_exit_task+0x170/0x1e9
[  447.919134]  [<ffffffff81046182>] ? release_task+0x22c/0x402
[  447.924859]  [<ffffffff8104789d>] ? do_exit+0x655/0x6e7
[  447.930144]  [<ffffffff810479ea>] ? complete_and_exit+0x0/0x16
[  447.936054]  [<ffffffff8100baab>] ? system_call_fastpath+0x16/0x1b

when running:

   perf stat ./hackbench_pth 20

release_task() is a deep-atomic context, we cannot acquire a mutex 
there. I'm not sure we can change that lock to a spinlock straight 
away.

	Ingo