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.
Yeah, please make sure that the targeted task is "current". -- 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/
