linux-kernel - ftrace trace_raw

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

Date:   Tue, 17 Dec 2019 17:44:40 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "'Steven Rostedt'" <rostedt@...dmis.org>
Subject: ftrace trace_raw_pipe format

I'm trying to 'grok' the trace_raw_pipe data that ftrace generates.
I've some 3rd party code that post-processes it, but doesn't like wrapped traces
because (I think) the traces from different cpus start at different times.

I can't seem to find any documentation at all...

I can find the format of the trace entries (I only need the length) from the 'format' files.
There seems to be 4 bytes between the entries that looks like a time difference.
I presume this is the interval before the trace item that follows.
(There is a time-delta of 1 before the first entry.)

The overall file seems to be a series of 4k blocks.
All but the first have a 16 byte header (possibly) described by 'header_page'
that has a timestamp and length (and a sign extended flag).

The first 4k page is confusing me.
The first 8 bytes might be the time the actual trace started.
The next 8 contain a length (short for a wrapped trace).
I've no idea what the next 8 are, they look like count of something.

Given that I've stopped tracing before reading the files I'd
expect the last buffer to be the partial one, not the first.
I'm also pretty sure the partial block contains the last trace data
(it seems to refer to the shell script sleep used to time the trace.)

I did find some old mailing list messages about these files being
corrupt - but that was about the time the splice code was
added to read them out - best part of 10 years ago.

If I can sort the headers for the 4k block (and reorder them??),
then delete entries so the start times match I should be able to
make the post-processing code work.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)