linux-kernel - Re: [RFC][PATCH 1/2] perf: Add 'perf kmem' tool

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: <20091123065110.GC31758@elte.hu>
Date:	Mon, 23 Nov 2009 07:51:10 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Arnaldo Carvalho de Melo <acme@...radead.org>
Cc:	Li Zefan <lizf@...fujitsu.com>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Eduard - Gabriel Munteanu <eduard.munteanu@...ux360.ro>,
	LKML <linux-kernel@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: [RFC][PATCH 1/2] perf: Add 'perf kmem' tool


* Arnaldo Carvalho de Melo <acme@...radead.org> wrote:

> Em Fri, Nov 20, 2009 at 05:41:10PM +0100, Ingo Molnar escreveu:
> > > So we have a mechanism that is already present in several distros
> > > (build-id), that is in the kernel build process since ~2.6.23, and that
> > > avoids using mismatching DSOs when resolving symbols.
> > 
> > But what do we do if we have another box that runs say on a MIPS CPU, 
> > uses some minimal distro - and copy that perf.data over to an x86 box.
> 
> There would be no problem, it would be just a matter of installing the
> right -debuginfo packages, for MIPS.

I havent tried this - is this really possible to do on an x86 box, with 
a typical distro? Can i install say Fedora PowerPC debuginfo packages on 
an x86 box, while also having the x86 debuginfo packages there?

> Or the original, unstripped FS image sent to the machine with the MIPS 
> cpu, if there aren't -debuginfo packages.
> 
> Either one, the right DSOs would be found by the buildids.
> 
> There are other scenarios, like a binary that gets updated while a long
> running perf record session runs, the way to differentiate between the
> two DSOs wouldn't be the name, but the buildid.
> 
> > The idea is there to be some new mode of perf.data where all the 
> > relevant DSO contents (symtabs but also sections with instructions for 
> > perf annotate to work) are copied into perf.data, during or after data 
> > capture - on the box that does the recording.
> > 
> > Once we have everything embedded in the perf.data, analysis passes only 
> > have to work based on that particular perf.data - no external data.
> 
> Well, we can that, additionally, but think about stripped binaries, we 
> would lose potentially a lot because the symtabs on that small machine 
> would have poorer symtabs than the ones in an unstriped binary (or in 
> a -debuginfo package).

We should definitely use the widest and best quality information we can 
- if it's available.

So even if we 'inline' any information from the box, if there's better 
info available at the time of analysis, we should use that too.

Basically what matters is the principle of 'what is possible'.

If a user records on a box and analyses on a different box, and we end 
up not doing something (and printing an error or displaying an empty 
profile) that could reasonably have been done, then the user will be 
unhappy and we might lose that user.

The user wont be unhappy about us using a big set of data sources that 
we can recover information from transparently. The user will be unhappy 
if we insist on (and force) a certain form of information source - such 
as debuginfo.

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