linux-kernel - Re: [PATCH] perf: detect loops processing events

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 09 May 2013 19:40:39 -0600
From:	David Ahern <dsahern@...il.com>
To:	Namhyung Kim <namhyung@...nel.org>
CC:	Ingo Molnar <mingo@...nel.org>, acme@...stprotocols.net,
	linux-kernel@...r.kernel.org,
	Frederic Weisbecker <fweisbec@...il.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Jiri Olsa <jolsa@...hat.com>,
	Stephane Eranian <eranian@...gle.com>
Subject: Re: [PATCH] perf: detect loops processing events

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/