On Wed, May 20, 2015 at 05:26:07PM +0200, Peter Zijlstra wrote:
> Except of course that ->event_init() likes to do an allocation :/
>
> Needs to be fixed differently.
So this puts the lock in the x86 code, it seems to build and run.
But my brain is fried after staring at this pmu scheduling code all day,
so maybe its wrong again.
Stephane, can you have a look?
---
diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index 87848eb..344bb90 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -1823,6 +1823,9 @@ static int validate_group(struct perf_event *event)
fake_cpuc = allocate_fake_cpuc();
if (IS_ERR(fake_cpuc))
return PTR_ERR(fake_cpuc);
+
+
+ raw_spin_lock_irq(&leader->ctx->lock);
/*
* the event is not yet connected with its
* siblings therefore we must first collect
@@ -1843,6 +1846,8 @@ static int validate_group(struct perf_event *event)
ret = x86_pmu.schedule_events(fake_cpuc, n, NULL);
out:
+ raw_spin_unlock_irq(&leader->ctx->lock);
+
free_fake_cpuc(fake_cpuc);
return ret;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
