[tip:perf/urgent] perf: perf_event_exit_task_context: s/rcu_dereference/rcu_dereference_raw/

[tip-bot for Oleg Nesterov]

Commit-ID:  806839b22cbda90176d7f8d421889bddd7826e93
Gitweb:     http://git.kernel.org/tip/806839b22cbda90176d7f8d421889bddd7826e93
Author:     Oleg Nesterov <oleg@xxxxxxxxxx>
AuthorDate: Fri, 21 Jan 2011 18:45:47 +0100
Committer:  Ingo Molnar <mingo@xxxxxxx>
CommitDate: Fri, 21 Jan 2011 22:08:16 +0100

perf: perf_event_exit_task_context: s/rcu_dereference/rcu_dereference_raw/

In theory, almost every user of task->child->perf_event_ctxp[]
is wrong. find_get_context() can install the new context at any
moment, we need read_barrier_depends().

dbe08d82ce3967ccdf459f7951d02589cf967300 "perf: Fix
find_get_context() vs perf_event_exit_task() race" added
rcu_dereference() into perf_event_exit_task_context() to make
the precedent, but this makes __rcu_dereference_check() unhappy.
Use rcu_dereference_raw() to shut up the warning.

Reported-by: Ingo Molnar <mingo@xxxxxxx>
Signed-off-by: Oleg Nesterov <oleg@xxxxxxxxxx>
Cc: acme@xxxxxxxxxx
Cc: paulus@xxxxxxxxx
Cc: stern@xxxxxxxxxxxxxxxxxxx
Cc: a.p.zijlstra@xxxxxxxxx
Cc: fweisbec@xxxxxxxxx
Cc: roland@xxxxxxxxxx
Cc: prasad@xxxxxxxxxxxxxxxxxx
Cc: Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx>
LKML-Reference: <20110121174547.GA8796@xxxxxxxxxx>
Signed-off-by: Ingo Molnar <mingo@xxxxxxx>
---
 kernel/perf_event.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/kernel/perf_event.c b/kernel/perf_event.c
index c5fa717..126a302 100644
--- a/kernel/perf_event.c
+++ b/kernel/perf_event.c
@@ -6136,7 +6136,7 @@ static void perf_event_exit_task_context(struct task_struct *child, int ctxn)
 	 * scheduled, so we are now safe from rescheduling changing
 	 * our context.
 	 */
-	child_ctx = rcu_dereference(child->perf_event_ctxp[ctxn]);
+	child_ctx = rcu_dereference_raw(child->perf_event_ctxp[ctxn]);
 	task_ctx_sched_out(child_ctx, EVENT_ALL);
 
 	/*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/