linux-kernel - Re: [PATCH 02/10] perf tool: fix: Don't discard prev in backward mode

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:   Wed, 11 Oct 2017 02:23:54 +0800
From:   "Wangnan (F)" <wangnan0@...wei.com>
To:     <kan.liang@...el.com>, <acme@...nel.org>, <peterz@...radead.org>,
        <mingo@...hat.com>, <linux-kernel@...r.kernel.org>
CC:     <jolsa@...nel.org>, <hekuang@...wei.com>, <namhyung@...nel.org>,
        <alexander.shishkin@...ux.intel.com>, <adrian.hunter@...el.com>,
        <ak@...ux.intel.com>
Subject: Re: [PATCH 02/10] perf tool: fix: Don't discard prev in backward mode

On 2017/10/11 1:20, kan.liang@...el.com wrote:
> From: Kan Liang <kan.liang@...el.com>
>
> Perf record can switch output. The new output should only store the data
> after switching. However, in overwrite backward mode, the new output
> still have the data from old output.
>
> At the end of mmap_read, the position of processed ring buffer is saved
> in md->prev. Next mmap_read should be end in md->prev.
> However, the md->prev is discarded. So next mmap_read has to process
> whole valid ring buffer, which definitely include the old processed
> data.
>
> Set the prev as the end of the range in backward mode.
>
> Signed-off-by: Kan Liang <kan.liang@...el.com>
> ---
>   tools/perf/util/evlist.c | 14 +++++++++++++-
>   1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
> index 33b8837..7d23cf5 100644
> --- a/tools/perf/util/evlist.c
> +++ b/tools/perf/util/evlist.c
> @@ -742,13 +742,25 @@ static int
>   rb_find_range(void *data, int mask, u64 head, u64 old,
>   	      u64 *start, u64 *end, bool backward)
>   {
> +	int ret;
> +
>   	if (!backward) {
>   		*start = old;
>   		*end = head;
>   		return 0;
>   	}
>   
> -	return backward_rb_find_range(data, mask, head, start, end);
> +	ret = backward_rb_find_range(data, mask, head, start, end);
> +
> +	/*
> +	 * The start and end from backward_rb_find_range is the range for all
> +	 * valid data in ring buffer.
> +	 * However, part of the data is processed previously.
> +	 * Reset the end to drop the processed data
> +	 */
> +	*end = old;
> +

I don't understand this patch. What rb_find_range() wants to do is to 
find start
and end pointer, so record__mmap_read() knows where to start reading and 
where to stop.
In backward mode, 'start' pointer is clearly 'head' (because 'head' is 
the header of the
last record kernel writes to the ring buffer), but the 'end' pointer is 
not very easy to
find ('end' pointer is the last (the earliest) available record in the 
ring buffer).
We have to parse the whole ring buffer to find the last available record 
and set its
tail into 'end', this is what backward_rb_find_range() tries hard to do. 
However,
your patch unconditionally overwrites *end (which is set by 
backward_rb_find_range()),
makes backward_rb_find_range() meaningless.

In my mind when you decide to use backward ring buffer you must make it 
overwrite
because you want the kernel silently overwrite old records without 
waking up perf, while
still able to parse the ring buffer even if overwriting happens. The use 
case
should be: perf runs in background, kernel silently ignores old records 
in the ring
buffer until something bad happens, then perf dumps 'events before the 
bad thing'.
Similar to fight recorder. In this use case, each dumping is 
independent. Even
if one record is appears in previous dumping, it is harmless (and 
useful) to make
it appears in following dumping again.

If you really want to avoid record duplication, you need to changes 
record__mmap_read()'s
logic. Now it complains "failed to keep up with mmap data" and avoid 
dumping data when
size of newly generated data is larger than the size of the ring buffer. 
It is reasonable
for forward ring buffer because in this case you lost the head of the 
first record, the
whole ring buffer is unparseable. However, it is wrong in backward case. 
What you
should do in this case is dumping the whole ring buffer.

> +	return ret;
>   }
>   
>   /*