Re: [PATCH] perf_counter: Provide functions for locking andpinning the context for a task

[Paul Mackerras]

Ingo Molnar writes:

> Yeah, indeed that box has a CPU hotplug testcase - sets cpu1 to 
> offline then online.
> 
> There should be no counters active anywhere during that.

OK, I can't reproduce this on powerpc.  I guess you have dynamic
per-cpu patches in there, and per-cpu areas are getting reinitialized
when cpus come up.  That, combined with the fact that the
migration_notifier in kernel/sched.c puts itself at priority 10, means
that we're getting a call to perf_counter_task_migration() for a
newly-added CPU before perf_cpu_notify() has been called for that CPU,
and so we're trying to use an uninitialized perf_cpu_context and we go
boom.

Could you try the same test with this patch?  If this fixes it, then
that's what the problem is.  It's up to you whether increasing the
priority on perf_cpu_nb is the right solution or whether we should
solve the problem some other way.

Paul.

diff --git a/kernel/perf_counter.c b/kernel/perf_counter.c
--- a/kernel/perf_counter.c
+++ b/kernel/perf_counter.c
@@ -3902,8 +3902,12 @@ perf_cpu_notify(struct notifier_block *self, unsigned long action, void *hcpu)
 	return NOTIFY_OK;
 }
 
+/*
+ * This has to have a higher priority than migration_notifier in sched.c.
+ */
 static struct notifier_block __cpuinitdata perf_cpu_nb = {
 	.notifier_call		= perf_cpu_notify,
+	.priority		= 20,
 };
 
 void __init perf_counter_init(void)
--
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/