summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorFrederic Weisbecker <fweisbec@gmail.com>2013-08-02 18:29:54 +0200
committerIngo Molnar <mingo@kernel.org>2013-08-16 17:55:50 +0200
commitfc3b86d673e41ac66b4ba5b75a90c2fcafb90089 (patch)
tree9fe09945405a9fc0a63b1481a7f943308156ca1e
parent77b339bce3e21f7a069447fc25a414b18e36fa2e (diff)
downloadlinux-fc3b86d673e41ac66b4ba5b75a90c2fcafb90089.tar.bz2
perf: Roll back callchain buffer refcount under the callchain mutex
When we fail to allocate the callchain buffers, we roll back the refcount we did and return from get_callchain_buffers(). However we take the refcount and allocate under the callchain lock but the rollback is done outside the lock. As a result, while we roll back, some concurrent callchain user may call get_callchain_buffers(), see the non-zero refcount and give up because the buffers are NULL without itself retrying the allocation. The consequences aren't that bad but that behaviour looks weird enough and it's better to give their chances to the following callchain users where we failed. Reported-by: Jiri Olsa <jolsa@redhat.com> Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com> Acked-by: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Stephane Eranian <eranian@google.com> Signed-off-by: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/1375460996-16329-2-git-send-email-fweisbec@gmail.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
-rw-r--r--kernel/events/callchain.c3
1 files changed, 2 insertions, 1 deletions
diff --git a/kernel/events/callchain.c b/kernel/events/callchain.c
index 76a8bc5f6265..97b67df8fbfe 100644
--- a/kernel/events/callchain.c
+++ b/kernel/events/callchain.c
@@ -116,10 +116,11 @@ int get_callchain_buffers(void)
err = alloc_callchain_buffers();
exit:
- mutex_unlock(&callchain_mutex);
if (err)
atomic_dec(&nr_callchain_events);
+ mutex_unlock(&callchain_mutex);
+
return err;
}