public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Vince Weaver <vincent.weaver@maine.edu>
Cc: Ingo Molnar <mingo@kernel.org>,
	linux-kernel@vger.kernel.org, eranian@google.com,
	Paul Mackerras <paulus@samba.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>
Subject: Re: [patch] inherited events not signalling parent on overflow
Date: Thu, 11 Jun 2015 10:32:01 +0200	[thread overview]
Message-ID: <1434011521.1495.71.camel@twins> (raw)
In-Reply-To: <alpine.DEB.2.20.1506110025540.13723@vincent-weaver-1.umelst.maine.edu>

On Thu, 2015-06-11 at 00:30 -0400, Vince Weaver wrote:
> On Fri, 29 May 2015, Ingo Molnar wrote:
>  
> > * Vince Weaver <vincent.weaver@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.weaver@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.

Right, I had a peek earlier at how fasync worked but came away confused.

Today I seem to have had better luck. Installing fasync allocates memory
and sets filp->f_flags |= FASYNC, which upon the demise of the file
descriptor ensures the allocation is freed.

Now for perf, we can have the events stick around for a while after the
original FD is dead because of references from child events. With the
above patch these events would still have a pointer into this free'd
fasync. This is bad.

A further problem with the patch is that if the parent changes its
fasync state the children might lag and again have pointers into dead
space.

All is not lost though; does something like the below work?

---
 kernel/events/core.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 1e33b9141f03..057f599ae0dc 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -4742,12 +4742,20 @@ static const struct file_operations perf_fops = {
  * to user-space before waking everybody up.
  */
 
+static inline struct fasync_struct **perf_event_fasync(struct perf_event *event)
+{
+	/* only the parent has fasync state */
+	if (event->parent)
+		event = event->parent;
+	return &event->fasync;
+}
+
 void perf_event_wakeup(struct perf_event *event)
 {
 	ring_buffer_wakeup(event);
 
 	if (event->pending_kill) {
-		kill_fasync(&event->fasync, SIGIO, event->pending_kill);
+		kill_fasync(perf_event_fasync(event), SIGIO, event->pending_kill);
 		event->pending_kill = 0;
 	}
 }
@@ -6126,7 +6134,7 @@ static int __perf_event_overflow(struct perf_event *event,
 	else
 		perf_event_output(event, data, regs);
 
-	if (event->fasync && event->pending_kill) {
+	if (*perf_event_fasync(event) && event->pending_kill) {
 		event->pending_wakeup = 1;
 		irq_work_queue(&event->pending);
 	}


  reply	other threads:[~2015-06-11  8:32 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-28 19:06 [patch] inherited events not signalling parent on overflow Vince Weaver
2015-05-28 19:15 ` Peter Zijlstra
2015-05-29 16:45   ` Vince Weaver
2015-05-29  6:36 ` Ingo Molnar
2015-06-11  4:30   ` Vince Weaver
2015-06-11  8:32     ` Peter Zijlstra [this message]
2015-07-31  4:42       ` Vince Weaver
2015-07-31  9:26         ` Peter Zijlstra
2015-08-04  8:51       ` [tip:perf/urgent] perf: Fix fasync handling on inherited events tip-bot for Peter Zijlstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1434011521.1495.71.camel@twins \
    --to=peterz@infradead.org \
    --cc=acme@kernel.org \
    --cc=eranian@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=paulus@samba.org \
    --cc=vincent.weaver@maine.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox