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]

Message-ID: <alpine.DEB.1.10.0811262001270.1501@gandalf.stny.rr.com>
Date:	Wed, 26 Nov 2008 20:08:07 -0500 (EST)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Frédéric Weisbecker <fweisbec@...il.com>
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

> 
> 
> 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);

-- Steve

--
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/