On Wed, Jul 25, 2012 at 05:02:56PM +0530, Naveen N. Rao wrote:> >>>@@ -453,7 +453,15 @@ int modify_user_hw_breakpoint(struct perf_event> >>>*bp, struct perf_event_attr *att> >>> int old_type = bp->attr.bp_type;> >>> int err = 0;> >>>> >>>- perf_event_disable(bp);> >>>+ /*> >>>+ * modify_user_hw_breakpoint can be invoked with IRQs disabled> >>>and hence it> >>>+ * will not be possible to raise IPIs that invoke> >>>__perf_event_disable.> >>>+ * So call the function directly.> >>>+ */> >>>+ if (irqs_disabled())> >>>+ __perf_event_disable(bp);> >>>+ else> >>>+ perf_event_disable(bp);> >>> >>This only works if we are sure the bp is on the current CPU. Do we> >>have that guarantee?> >> >Yes. This is being hit during bp exception processing and is specific to> >ppc where we disable interrupts:> >hw_breakpoint_handler->perf_bp_event->ptrace_triggered->modify_user_hw_breakpoint()> > Frederick,> Is this acceptable, or do you have other scenarios where this won't> work? I can add a check to ensure we call __perf_event_disable only> if the task is on the current CPU, but the above scenario is the> only one where we're seeing this issue.