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
| ||
|
Date: Tue, 19 Jan 2016 12:48:37 -0300 From: Arnaldo Carvalho de Melo <acme@...nel.org> To: Peter Zijlstra <peterz@...radead.org> Cc: Namhyung Kim <namhyung@...nel.org>, Ingo Molnar <mingo@...nel.org>, Stephane Eranian <eranian@...gle.com>, LKML <linux-kernel@...r.kernel.org>, Jiri Olsa <jolsa@...nel.org>, Adrian Hunter <adrian.hunter@...el.com>, "ak@...ux.intel.com" <ak@...ux.intel.com> Subject: Re: [RFC] perf record: missing buildid for callstack modules Em Tue, Jan 19, 2016 at 04:27:42PM +0100, Peter Zijlstra escreveu: > On Tue, Jan 19, 2016 at 11:56:40PM +0900, Namhyung Kim wrote: > > > > But but ... why is #2 a problem with mtime? If we have an out of date record in > > > the perf.data, then the perf.data is uninteresting in 99% of the usecases! It's > > > out of date, most likely because the binary the developer is working on got > > > rebuilt, or the system got upgraded - in both cases the developer does not care > > > about the old records anymore... > > We have 'perf diff' command which compares old and new performance > > results of a same program. People can use it to see how much improved > > in the new version than the baseline. In this case, the old binary > > should be found from the old perf.data. > Just means they'll have to use perf-archive or whatnot before that > works. Making the regular perf-record dead slow just so that a few more > complex workloads work doesn't make sense. And perf-diff will be able to find the right binaries in most cases, as we'll end up using that mtime to pick the right binary for the baseline and the other perf.data files used. So, if both files are reachable via the usual path (/usr/lib/debug, /bin/, /lib64, ~/.debug/, etc) it'll work. For users wanting the convenience of auto-saving binaries + its sources, then they will have to incur the cost of postprocessing the just generated perf.data file to do that, and make sure debuginfo is enabled, for having the sources embedded into those fat binaries. With the current situation, without any disambiguation mechanism, we _need_ to traverse the perf.data file to find that disambiguation bit, the build-id (we could'be been using the mtime, but having to traverse it all we may as well use something better, the build-id), and while doing that we could as well do a hardlink into ~/.debug/ for the DSOs found in PERF_RECORD_MMAP(2) meta events (a copy if that hardlink isn't possible, more overhead). Now we'll use that mtime, which should be good enough for both figuring out if a file can be used to even choose among various entries for a same pathname. And we'll cover the case where a DSO is replaced during a record session, as newer PERF_RECORD_MMAP3 emitted after the update will have a different mtime, yay! The extra, content based verification to double check that is the real DSO used, which we're not using anyway right now (but could) will not be possible, i.e. regenerate the build-id from the DSO contents to check that it is really what was present at the record phase. But for those super stringent needs, the door is open to add the content-based cookie at the end of the PERF_RECORD_MMAP3, as we have in it the filename-len, etc. So now, with PERF_RECORD_MMAP3 the onus of using this all is back at where it belongs, away from kernel developers and into tools/perf/ developers, tooling should use build-ids if available and if not, fallback to mtime, if even that is not available (older kernels) then warn the user and hope the pathname is enough. - Arnaldo
Powered by blists - more mailing lists