On Fri, 29 May 2015, Ingo Molnar wrote: > * Vince Weaver <vincent.wea...@maine.edu> wrote:
> > If we inherit events, we inherit the signal state but not the fasync state, > > so > > overflows in inherited children will never trigger the signal handler. > > > > Signed-off-by: Vince Weaver <vincent.wea...@maine.edu> > > > > diff --git a/kernel/events/core.c b/kernel/events/core.c > > index 1a3bf48..7df4cf5 100644 > > --- a/kernel/events/core.c > > +++ b/kernel/events/core.c > > @@ -8626,6 +8630,8 @@ inherit_event(struct perf_event *parent_event, > > child_event->overflow_handler_context > > = parent_event->overflow_handler_context; > > > > + child_event->fasync = parent_event->fasync; > > + > > /* > > * Precalculate sample_data sizes > > */ This patch, while it does work well enough to enable self-monitored-sampling of OpenMP programs, falls apart under fuzzing. You end up with lots of [25592.289382] kill_fasync: bad magic number in fasync_struct! warnings and eventually I managed to lock up the system that way. > Btw., if we do this (sensible looking) ABI fix, could we make it a new attr > bit, > so that PAPI can essentially query the kernel whether this gets propagated > properly? > > That way old kernels 'intentionally' don't inherit the fasync handler and > tooling > can deterministically make use of this 'feature' on new kernels. That would be useful. PAPI typically has to guess about feature support (for workarounds) by using the kernel version number as a reference, and this falls apart on kernels such as RHEL which backport a lot of perf_event fixes/functionality. Vince -- 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/
