linux-kernel - Re: [PATCH] perf: make perf.data more self-descriptive (v8)

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

Date:	Mon, 19 Dec 2011 10:26:16 +0100
From:	Robert Richter <robert.richter@....com>
To:	Stephane Eranian <eranian@...gle.com>
CC:	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>,
	"dsahern@...il.com" <dsahern@...il.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	"acme@...hat.com" <acme@...stprotocols.net>,
	"mingo@...e.hu" <mingo@...e.hu>,
	"ak@...ux.intel.com" <ak@...ux.intel.com>
Subject: Re: [PATCH] perf: make perf.data more self-descriptive (v8)

On 18.12.11 20:49:42, Stephane Eranian wrote:
> On Dec 6, 2011 10:29 AM, "Robert Richter" <robert.richter@....com> wrote:
> >
> > On 05.12.11 11:24:05, Stephane Eranian wrote:
> > > The one thing I realized last week, is that all that header information,
> incl.
> > > the features bits do not seem to appear in the file perf.data file when you
> > > use the perf record pipe mode. We need to fix that otherwise, if you
> > > depend on information in those bits, it won't always be present. That's
> > > a major issue.
> >
> > Yes, this is because pipes are not seakable, which is necessary to
> > write the features.

> Yes, but we should have those headers regardless. They contain very useful info
> about the measurement. The seeks should not be required. The features can be at
> the end of data. We should not have to care how the perf.data file was created
> by the time we call perf report. Something looks broken to me here.

It must not necessarilly at the end of the file. Using lseek() makes
the implementation much more easy. If you have to write data
sequentially you must store later parts temporarilly in memory until
earlier parts are complete. E.g. you write a size value of null, write
all remaining data and then seek back to size to write the actuall
size.

I aggree, having the header information (or at least parts of it) not
in the pipe stream will cause some implications, such as that the
information get lost if piping through the network to a different
system.

We would have to rewrite large portions of the code to write data
without seeks.

-Robert

-- 
Advanced Micro Devices, Inc.
Operating System Research Center

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