On Mon, 21 Mar 2016, Matt Fleming wrote:
On Mon, 21 Mar, at 02:53:04AM, tip-bot for Vikas Shivappa wrote:@@ -489,6 +496,22 @@ static u32 intel_cqm_xchg_rmid(struct perf_event *group, u32 rmid) raw_spin_unlock_irq(&cache_lock); + /* + * If the allocation is for mbm, init the mbm stats. + * Need to check if each event in the group is mbm event + * because there could be multiple type of events in the same group. + */ + if (__rmid_valid(rmid)) { + event = group; + if (is_mbm_event(event->attr.config)) + init_mbm_sample(rmid, event->attr.config); + + list_for_each_entry(event, head, hw.cqm_group_entry) { + if (is_mbm_event(event->attr.config)) + init_mbm_sample(rmid, event->attr.config); + } + } + return old_rmid; }You're calling init_mbm_sample() without holding cache_lock. Won't this potentially trash the existing value in MSR_IA32_QM_EVTSEL, if say, we're reading the counter at the same time as the recycling worker is running?
The init_mbm_sample calls the update_sample to read the MSR in IPI .. Since the count is also in IPI , they should not trash each other ?
Basically all the MSR read/writes are in high irql , except for the mbm overflow timer and read calls which holds an irqsave spinlock.
Thanks, Vikas
-- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|