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] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 10 May 2013 10:10:16 +0900
From:	Namhyung Kim <namhyung@...nel.org>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	David Ahern <dsahern@...il.com>, 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

Hi Ingo,

On Thu, 9 May 2013 11:30:25 +0200, Ingo Molnar wrote:
> * Ingo Molnar <mingo@...nel.org> wrote:
>> Btw., would it make sense to emit a (once-only) warning and optimistically 
>> fix page_offset up to 1 (or 4096) and let things continue with the next 
>> set of data - can we recover most of the data in that case?
>
> Basically, what'd like to do with binary data is similar to what we do 
> with text data if some trace output is corrupted:
>
>             sshd-15478 [002]  1100.859353:  15478:120:S ==> [002]     0:140:R <idle>
>           <idle>-0     [005]  1100.859378:      0:140:R ==> [005] 20169:120:R cat
>              cat-20169 [005]  1100.860718:  20169:120:R   + [005] 15521:120:S bash
>              ^@¨<81><92>^@^Bª^P^P^D<9c>8@<88>^A^M ;¤0 ^D<90>"ª<81>^B^T)Ò^C$^@^N^@^A
>              cat-20169 [005]  1100.860720:  20169:120:R   + [005]   305:115:S kblockd/5
>              cat-20169 [005]  1100.860722:  20169:120:? ==> [005]   305:115:R kblockd/5
>        kblockd/5-305   [005]  1100.860755:    305:115:S ==> [005] 15521:120:R bash
>             bash-15521 [005]  1100.860792:  15521:120:S   + [002] 15478:120:S sshd
>           <idle>-0     [002]  1100.860853:      0:140:R ==> [002] 15478:120:R sshd
>             sshd-15478 [002]  1100.860895:  15478:120:S ==> [002]     0:140:R <idle>
>             bash-15521 [005]  1100.860925:  15521:120:S   + [002] 15478:120:S sshd
>             bash-15521 [005]  1100.860999:  15521:120:S ==> [005]     0:140:R <idle>
>
> See that junk in the middle, sign of some sort of file corruption? Instead 
> of detecting it and aborting we just try to skip that line and try to find 
> the next useful looking line, ignoring the junk and bits around it.
>
> Is there a perf.data equivalent of intelligently trying to skip to the 
> next plausible looking event record?

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;


-- 
Thanks,
Namhyung
--
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/