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]

Date:	Tue, 22 May 2012 22:01:57 -0300
From:	Arnaldo Carvalho de Melo <acme@...hat.com>
To:	Namhyung Kim <namhyung.kim@....com>
Cc:	Stephane Eranian <eranian@...gle.com>,
	Peter Zijlstra <peterz@...radead.org>,
	David Ahern <dsahern@...il.com>, linux-kernel@...r.kernel.org,
	mingo@...nel.org
Subject: Re: [PATCH v2 4/5] perf record: add meta-data support for pipe-mode

Em Wed, May 23, 2012 at 09:45:12AM +0900, Namhyung Kim escreveu:
> On Tue, 22 May 2012 19:51:15 +0200, Stephane Eranian wrote:
> > 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.
> >
> 
> IIUC, to add build-ids we should check all dso's whether hits or not,
> but it's not same as the case of meta-data since we can know it before
> processing. Am I missing something?

To add build ids properly we should read it when the kernel loads a DSO,
so that when PERF_RECORD_MMAP is sent to the event stream, the build id
is there, so no need for post processing, etc.

The way we do it now is racy, long running sessions may experience DSO
updating, etc.

I think we can figure out a way to avoid the seeks Stephane mentions so
to get something done as Peter suggests.

But at the same time I don't think reusing the existing mechanism is
such a big problem as Peter makes of it :-\

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