All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Jiri Olsa <jolsa@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH] perf tools: session: avoid infinite loop
Date: Fri, 18 Sep 2015 12:29:57 -0300	[thread overview]
Message-ID: <20150918152957.GU11551@kernel.org> (raw)
In-Reply-To: <20150918151851.GC31683@leverpostej>

Em Fri, Sep 18, 2015 at 04:18:51PM +0100, Mark Rutland escreveu:
> On Fri, Sep 18, 2015 at 04:00:18PM +0100, Arnaldo Carvalho de Melo wrote:
> > After applying your patch it works, had to tweak the commit log to avoid
> > starting lines with ---, breaks git scripts, also added a commiter log,
> > check it, patch is below, after the one I used to not process any
> > samples.
 
> Sorry for the '---' problem, I'll bear that in mind in future.
 
> Your commit log looks fine, though I'm slightly confused by the
> Reported-by line -- did you mean to add that?

Sorry, I mean Tested-by:, will replace, guess i can replace the one for
Adrian from Cc: to Tested-by too, right?

- Arnaldo
 
> Mark.
> 
> > commit dd486ec4aa33cfca2fd912ef501d49909005de79
> > Author: Mark Rutland <mark.rutland@arm.com>
> > Date:   Wed Sep 16 18:18:49 2015 +0100
> > 
> >     perf record: Avoid infinite loop at buildid processing with no samples
> >     
> >     If a session contains no events, we can get stuck in an infinite loop in
> >     __perf_session__process_events, with a non-zero file_size and data_offset, but
> >     a zero data_size.
> >     
> >     In this case, we can mmap the entirety of the file (consisting of the file and
> >     attribute headers), and fetch_mmaped_event will correctly refuse to read any
> >     (unmapped and non-existent) event headers. This causes
> >     __perf_session__process_events to unmap the file and retry with the exact same
> >     parameters, getting stuck in an infinite loop.
> >     
> >     This has been observed to result in an exit-time hang when counting
> >     rare/unschedulable events with perf record, and can be triggered artificially
> >     with the script below:
> >     
> >       ----
> >       #!/bin/sh
> >       printf "REPRO: launching perf\n";
> >       ./perf record -e software/config=9/ sleep 1 &
> >       PERF_PID=$!;
> >       sleep 0.002;
> >       kill -2 $PERF_PID;
> >       printf "REPRO: waiting for perf (%d) to exit...\n" "$PERF_PID";
> >       wait $PERF_PID;
> >       printf "REPRO: perf exited\n";
> >       ----
> >     
> >     To avoid this, have __perf_session__process_events bail out early when
> >     the file has no data (i.e. it has no events).
> >     
> >     Commiter note:
> >     
> >     I only managed to reproduce this when setting
> >     /proc/sys/kernel/kptr_restrict to '1' and changing the code to
> >     purposefully not process any samples and no synthesized samples, i.e.
> >     kptr_restrict prevents 'record' from synthesizing the kernel mmaps for
> >     vmlinux + modules and since it is a workload started from perf, we don't
> >     synthesize mmap/comm records for existing threads.
> >     
> >     Adrian Hunter managed to reproduce it in his environment tho.
> >     
> >     Reported-by: Arnaldo Carvalho de Melo <acme@kernel.org>
> >     Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> >     Cc: Adrian Hunter <adrian.hunter@intel.com>
> >     Cc: Jiri Olsa <jolsa@redhat.com>
> >     Cc: Peter Zijlstra <peterz@infradead.org>
> >     Link: http://lkml.kernel.org/r/1442423929-12253-1-git-send-email-mark.rutland@arm.com
> >     Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
> > 
> > diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
> > index 8a4537ee9bc3..fc3f7c922f99 100644
> > --- a/tools/perf/util/session.c
> > +++ b/tools/perf/util/session.c
> > @@ -1580,7 +1580,10 @@ static int __perf_session__process_events(struct perf_session *session,
> >  	file_offset = page_offset;
> >  	head = data_offset - page_offset;
> >  
> > -	if (data_size && (data_offset + data_size < file_size))
> > +	if (data_size == 0)
> > +		goto out;
> > +
> > +	if (data_offset + data_size < file_size)
> >  		file_size = data_offset + data_size;
> >  
> >  	ui_progress__init(&prog, file_size, "Processing events...");
> > 

  reply	other threads:[~2015-09-18 15:30 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-16 17:18 [PATCH] perf tools: session: avoid infinite loop Mark Rutland
2015-09-16 20:54 ` Arnaldo Carvalho de Melo
2015-09-17 15:41   ` Mark Rutland
2015-09-18  6:09     ` Adrian Hunter
2015-09-18  9:51       ` Mark Rutland
2015-09-18 10:55         ` Adrian Hunter
2015-09-18 13:37           ` Mark Rutland
2015-09-18 15:00             ` Arnaldo Carvalho de Melo
2015-09-18 15:18               ` Mark Rutland
2015-09-18 15:29                 ` Arnaldo Carvalho de Melo [this message]
2015-09-21 12:33                   ` Adrian Hunter
2015-09-23  8:42 ` [tip:perf/core] perf record: Avoid infinite loop at buildid processing with no samples tip-bot for Mark Rutland

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=20150918152957.GU11551@kernel.org \
    --to=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.