From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750858AbbFKEZS (ORCPT ); Thu, 11 Jun 2015 00:25:18 -0400 Received: from mail-qk0-f175.google.com ([209.85.220.175]:35898 "EHLO mail-qk0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750698AbbFKEZN (ORCPT ); Thu, 11 Jun 2015 00:25:13 -0400 From: Vince Weaver X-Google-Original-From: Vince Weaver Date: Thu, 11 Jun 2015 00:30:53 -0400 (EDT) To: Ingo Molnar cc: Vince Weaver , linux-kernel@vger.kernel.org, peterz@infradead.org, eranian@google.com, Paul Mackerras , Arnaldo Carvalho de Melo Subject: Re: [patch] inherited events not signalling parent on overflow In-Reply-To: <20150529063650.GA22568@gmail.com> Message-ID: References: <20150529063650.GA22568@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 29 May 2015, Ingo Molnar wrote: > * Vince Weaver 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 > > > > 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