All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Ahern <dsahern@gmail.com>
To: Namhyung Kim <namhyung@kernel.org>
Cc: Ingo Molnar <mingo@kernel.org>,
	acme@ghostprotocols.net, linux-kernel@vger.kernel.org,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Jiri Olsa <jolsa@redhat.com>,
	Stephane Eranian <eranian@google.com>
Subject: Re: [PATCH] perf: detect loops processing events
Date: Thu, 09 May 2013 19:40:39 -0600	[thread overview]
Message-ID: <518C5017.3070407@gmail.com> (raw)
In-Reply-To: <87fvxv7i87.fsf@sejong.aot.lge.com>

On 5/9/13 7:10 PM, Namhyung Kim wrote:
>
> I think we should not truncate file_size for this case.  It was
> decreased to data_offset + data_size in order not to read unrelated
> metadata (additional header feature info).  But in this case, since
> data_size is 0 it'd have same value as data_offset, and in turn
> mmap_size truncated to data_offset too.  So fetch_mmaped_event() always
> return NULL as head + sizeof(event->header) exceeds mmap_size.
>
> If we keep original file_size, perf can report existing samples but no
> metadata.  So does the patch below make sense?
>
>
> diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
> index cf1fe01b7e89..cf4e574c7b7f 100644
> --- a/tools/perf/util/session.c
> +++ b/tools/perf/util/session.c
> @@ -1196,7 +1196,7 @@ int __perf_session__process_events(struct perf_session *session,
>          file_offset = page_offset;
>          head = data_offset - page_offset;
>
> -       if (data_offset + data_size < file_size)
> +       if (data_size && (data_offset + data_size < file_size))
>                  file_size = data_offset + data_size;
>
>          progress_next = file_size / 16;

Nice. That does handle the case of the perf.data file not getting closed 
properly. With this, my patch should not return -1 just print the error 
message to the user which would explain why the feature data is not printed.

David


      reply	other threads:[~2013-05-10  1:40 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-08 15:18 [PATCH] perf: detect loops processing events David Ahern
2013-05-09  9:24 ` Ingo Molnar
2013-05-09  9:30   ` Ingo Molnar
2013-05-10  1:10     ` Namhyung Kim
2013-05-10  1:40       ` David Ahern [this message]

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=518C5017.3070407@gmail.com \
    --to=dsahern@gmail.com \
    --cc=acme@ghostprotocols.net \
    --cc=eranian@google.com \
    --cc=fweisbec@gmail.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=namhyung@kernel.org \
    --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.