On Wed, Feb 04, 2015 at 03:51:36PM +0100, Jiri Olsa wrote: > On Mon, Feb 02, 2015 at 06:32:32PM +0100, Peter Zijlstra wrote: > > > That looks like tail recursive fun! An irq work that raises and irq work > > > ad infinitum. Lemme see if I can squash that.. didn't we have something > > > like this before... /me goes look. > > > > > > Does this make it go away? > > > > --- a/kernel/events/core.c > > +++ b/kernel/events/core.c > > @@ -4413,6 +4413,8 @@ static void perf_pending_event(struct ir > > struct perf_event *event = container_of(entry, > > struct perf_event, pending); > > > > + int rctx = perf_swevent_get_recursion_context(); > > + > > hum, you should check the rctx > > if (rctx == -1) > return;
D'uh, yes. > also this recursion is bound to swevent_htable, should we rather add > separate ctx data for irq_work to limit the clashing with SW events? No, we explicitly want to disable software events while handling the irq_work. The problem as reported looks like irq_work triggering a swevent (tp actually, but that's classed the same) generates a new irq_work, and we get stuck in an endless cycle of that. So by effectively disabling swevents while processing the irq_work we should break the cycle. -- 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/
