linux-kernel - Re: [PATCH] tracing/function-branch-tracer: enhancements for the trace output

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:	Thu, 27 Nov 2008 13:53:57 +0100
From:	"Frédéric Weisbecker" <fweisbec@...il.com>
To:	"Steven Rostedt" <rostedt@...dmis.org>
Cc:	"Ingo Molnar" <mingo@...e.hu>, "Tim Bird" <tim.bird@...sony.com>,
	"Linux Kernel" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] tracing/function-branch-tracer: enhancements for the trace output

2008/11/27 Steven Rostedt <rostedt@...dmis.org>:
>
>>
>>
>> One detail. If you get a trace through the "trace" file, you will have
>> no problem.
>> But if you cat trace_pipe, leaf functions are considered as nested.
>>
>> This is because iter->buffer_iter[iter->cpu]; is very often (always?)
>> false by using this file.
>> I don't know why yet....
>> But it makes the tracer unable to check the next entry to verify if it
>> matches its own return.
>
> That's because trace_pipe does not use an iterator ;-)  It is live stream.
>
> There's two cases: static read and consume.  On static read we can take
> our time and we iterate over the data in the file. The data does not get
> consumed so we use an iterator to traverse the data.
>
> The consume read will consume each entry as it reads it. We do not need an
> iterator for this because we are always reading the head of the file.
> After we read the data, that data is consumed and we read the next item.
>
> Hmm, I may need to make this apparent to the plugins like yours. This way
> you can do different things whether it is a static read or a consuming
> read.
>
> Perhaps the info now is what you already found out.
> "iter->buffer_iter[iter->cpu] will always be NULL when it is a consuming
> read. Intead you need to use:
>
> ring_buffer_peek instead of ring_buffer_iter_peek
>
> and
>
> ring_buffer_consume instead of ring_buffer_read
>
> This is the way you can use it:
>
> entry = ring_buffer_peek(iter->tr->buffer, iter->cpu, NULL);
> entry = ring_buffer_consume(iter->tr->buffer, iter->cpu, NULL);


Ok. Thanks, I will correct it by covering the two cases, like in
trace.c : peek_next_entry()
--
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/