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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <878un8hii3.fsf@sejong.aot.lge.com>
Date:	Fri, 01 Aug 2014 14:43:48 +0900
From:	Namhyung Kim <namhyung@...il.com>
To:	Arnaldo Carvalho de Melo <acme@...nel.org>
Cc:	"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
	Jiri Olsa <jolsa@...hat.com>
Subject: Re: perf tools: Question about kmem and kernel symbol resolution

On Thu, 31 Jul 2014 11:27:11 -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Jul 31, 2014 at 05:35:32PM +0900, Namhyung Kim escreveu:
>> I'm looking kernel symbol mismatch issue, and found something in perf
>> kmem code.  The commit e727ca73f85d ("perf kmem: Resolve kernel
>> symbols again") added perf_session__create_kernel_maps() but I don't
>> know why.  Why did it miss the MMAP event?
>  
>> I think if we create a kernel maps at report time, it might not match
>> to samples in a perf.data if it's recorded on a different kernel.
>> This is the main reason of the mismatch problem I'm currently chasing
>> IMHO.  What am I missing?
>
>> From a quick look, nothing, i.e. we can not call
> perf_session__create_kernel_maps() at that point, as it will create the
> kernel maps from the running kernel and use it with events from the
> kernel that was in place when the perf.data file being processed was
> created.
>
> Perhaps that problem was fixed somewhere else and we should just revert
> that patch?
>
> Have you tried just reverting it and checking that the results are the
> expected ones? I.e. that there is the kernel MMAP event in perf.data
> file and that it gets properly processed?

Simply reverting ended up with no symbols but it contains MMAP event for
sure.

Then I found a reason - it's simply because kmem tools doesn't register
mmap event handlers. :-/  Adding mmap[2] handlers + reverting ended up
with the expected output.

I'll send the fix soon.

Thanks,
Namhyung
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ