On 25/07/2017 02:20, Ben Widawsky wrote:
On 17-07-18 15:36:11, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
Without this I can get a null ptr deref when trying to access
our events with perf.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
This definitely seems unsafe, but should be squashed in somewhere
earlier...
Yep, the same for all patches at least up to this one. I did not want to
just take over Chris' patch, especially since the uncertainty on this
one however is that I am not sure whether the perf interactions are
correct. Action on me here, as discussed in cover letter discussion, is
to try to get some clarification from Peter Zijlstra and what and how
exactly we should be doing. Now that I have the internal API
clarification from you I can tidy the series, respin, and do that.
Regards,
Tvrtko
---
drivers/gpu/drm/i915/i915_pmu.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c
b/drivers/gpu/drm/i915/i915_pmu.c
index 4d61a1e72ee6..4195d89b1c82 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -183,8 +183,11 @@ static int engine_event_init(struct perf_event
*event)
return 0;
}
+static DEFINE_PER_CPU(struct pt_regs, i915_pmu_pt_regs);
+
static enum hrtimer_restart hrtimer_sample(struct hrtimer *hrtimer)
{
+ struct pt_regs *regs = this_cpu_ptr(&i915_pmu_pt_regs);
struct perf_sample_data data;
struct perf_event *event;
u64 period;
@@ -196,7 +199,7 @@ static enum hrtimer_restart hrtimer_sample(struct
hrtimer *hrtimer)
event->pmu->read(event);
perf_sample_data_init(&data, 0, event->hw.last_period);
- perf_event_overflow(event, &data, NULL);
+ perf_event_overflow(event, &data, regs);
period = max_t(u64, 10000, event->hw.sample_period);
hrtimer_forward_now(hrtimer, ns_to_ktime(period));
--
2.9.4
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
