linux-kernel - perf grows endlessly

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

Message-Id: <20120327.041820.1291740602811700132.davem@davemloft.net>
Date:	Tue, 27 Mar 2012 04:18:20 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	acme@...stprotocols.net
CC:	linux-kernel@...r.kernel.org
Subject: perf grows endlessly

This is easy to trigger, just run perf top or similar while something
loops doing "gcc -o foo ...; ./foo; rm foo;"  dsos__find() starts to
move up gradually in the profiles (yes, even if you turn the dso
lists into hash tables, guess what I tried first... :-)

Essentially, the problem is that perf never throws away dsos, so the
dso list grows every iteration of that loop.  This isn't a
manufactured test case, the glibc testsuite does this during it's
conformance test.  It's basically trying to build and execute a
program referencing a symbol, once for every symbol specified in
each and every standard (ISO, ISO99, POSIX, XPG3, etc.)

I suppose you could say this dso issue is indirectly related to the
issue discussed over the weekend where we refer to out-of-date maps
from hist entries.

Hist and thread entries do eventually get collapsed and purged, but
this just never propagates properly.

My initial impression is that we'll need to properly reference count
and periodically sweep dso objects are some point.
--
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/