| 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: Mon, 15 Oct 2012 15:44:36 -0400 (EDT) From: David Miller <davem@...emloft.net> To: a.p.zijlstra@...llo.nl CC: paulus@...ba.org, mingo@...hat.com, acme@...stprotocols.net, linux-kernel@...r.kernel.org Subject: [BUG] Perf refers to garbage events on 32-bit. When the perf tool is built 32-bit, it uses a sliding window mechanism to mmap the events from the perf.data file. However things stop working once we get past 8 times the 32-bit window size (which is 32MB). That's because the session code that reads in the events maintains an array of 8 mmap'd areas, and wraps around to the first, remapping it, if it runs through the full set of 8 entries. But this doesn't work since the perf backends maintain references to the entry pointers (in iterators, etc.). But after a remap, that entry points to a random location in the newly mmap()'d area. This means any perf.data file larger than 8 * 32MB cannot be correctly analyzed by the perf tools on 32-bit. The best solution is probably to make the mmap array variable size, trying to map everything in sliding window sized chunks, and fail if we run out of address space. There are hard dependencies in the perf code to being able to keep all of the events from a perf.data file in memory at one time. -- 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