linux-kernel - Re: [RFC][PATCH 2/2] perf: add perf-inject builtin

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

Date:	Sat, 1 May 2010 18:55:55 -0300
From:	Arnaldo Carvalho de Melo <acme@...stprotocols.net>
To:	Tom Zanussi <tzanussi@...il.com>
Cc:	linux-kernel@...r.kernel.org, mingo@...e.hu, fweisbec@...il.com,
	rostedt@...dmis.org
Subject: Re: [RFC][PATCH 2/2] perf: add perf-inject builtin

Em Sat, May 01, 2010 at 01:41:20AM -0500, Tom Zanussi escreveu:
> Currently, perf 'live mode' writes build-ids at the end of the
> session, which isn't actually useful for processing live mode events.
> 
> What would be better would be to have the build-ids sent before any of
> the samples that reference them, which can be done by processing the
> event stream and retrieving the build-ids on the first hit.  Doing
> that in perf-record itself, however, is off-limits.
> 
> This patch introduces perf-inject, which does the same job while
> leaving perf-record untouched.  Normal mode perf still records the
> build-ids at the end of the session as it should, but for live mode,
> perf-inject can be injected in between the record and report steps
> e.g.:
> 
> perf record -o - ./hackbench 10 | perf inject -v -b | perf report -v -i -
> 
> perf-inject reads a perf-record event stream and repipes it to stdout.
> At any point the processing code can inject other events into the
> event stream - in this case build-ids (-b option) are read and
> injected as needed into the event stream.
> 
> Build-ids are just the first user of perf-inject - potentially
> anything that needs userspace processing to augment the trace stream
> with additional information could make use of this facility.

Good work, I'd just make "read_buildid" be "dso__read_buildid", make its
'self' parameter be a struct dso pointer, first check if had its build
id read already, read it if not. Yeah, dsos can change, but that is also
not supported in 'perf record', where we do it at the end.

I.e. reducing the cost of build-id processing even in live mode is also
interesting and OK for the normal case of not changing DSOs while a
session is running.

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