linux-kernel - Re: [PATCH v2 4/5] perf record: add meta-data support for pipe-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]

Message-ID: <CABPqkBTQ=K-=qkgzC0TZPi1xyHtqT6QQroRg-7o0k8rFmjH_Bw@mail.gmail.com>
Date:	Tue, 22 May 2012 19:51:15 +0200
From:	Stephane Eranian <eranian@...gle.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Arnaldo Carvalho de Melo <acme@...hat.com>,
	David Ahern <dsahern@...il.com>, linux-kernel@...r.kernel.org,
	mingo@...e.hu
Subject: Re: [PATCH v2 4/5] perf record: add meta-data support for pipe-mode

On Tue, May 22, 2012 at 7:33 PM, Peter Zijlstra <peterz@...radead.org> wrote:
> On Fri, 2012-05-18 at 14:19 -0300, Arnaldo Carvalho de Melo wrote:
>
>> PeterZ was the one objecting to adding more userspace only events,
>
> Ah, yes I was ;-)
>
> So uhm the argument was something like perf_event_type is a kernel enum
> and userspace stealing space there is going to get us into trouble
> eventually since userspace doesn't register its types in our enum.
>
Yes, I did not start this but I understand why it was done that way.

The problem is that the headers as they are written to the file need
seeking in the file to update the offset table. That is NOT possible when
you operate in pipe mode. As such you need to inject the header infos
very much like kernel PERF_RECORD_*. That is also why you have
perf inject -b. Buildids are added at the end of the run in file mode,
and that's another seek to the offset table if I recall correctly.

So we need some namespace, so we can tag certain records as
"synthetic" vs. kernel-generated. The way it was done is to assume
that the kernel is not going to have more than 63 type of record types.
That's where we run the risk of overlap one day. But for now we are
at 10 kernel record types.

As such you need to inject certain header infos in the stream of kernel
> Furthermore most (if not all) the userspace thingies were setup (like in
> this case single session meta-data) things. So they don't belong in the
> event stream at all.
>
> From what I can remember all this is somehow related to how data is
> passed to scripts or so and since there's only a single stdin everything
> is stuffed over it.
>
> For the data file we should simply create another section in the header;
> and I think that is how it works these days.
>
> For the script muck, I've really no idea how all that works, but why
> can't you wrap the stuff in another layer; have a header up front that
> says the next N bytes are meta-data and after that there's the regular
> data stream.
>
> Or take some inspiration from one of the many multi-stream stream
> formats out there like mpeg or ogg or whatever.
--
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/