linux-kernel - Re: [PATCH 11/19] perf record: Release resources at exit

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

Date:	Mon, 2 Aug 2010 11:49:37 -0300
From:	Arnaldo Carvalho de Melo <acme@...radead.org>
To:	Nick Piggin <npiggin@...e.de>
Cc:	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	Frederic Weisbecker <fweisbec@...il.com>,
	Mike Galbraith <efault@....de>,
	Peter Zijlstra <peterz@...radead.org>,
	Stephane Eranian <eranian@...gle.com>
Subject: Re: [PATCH 11/19] perf record: Release resources at exit

Em Mon, Aug 02, 2010 at 07:59:47PM +1000, Nick Piggin escreveu:
> On Mon, Aug 02, 2010 at 11:17:14AM +0200, Ingo Molnar wrote:
> > Most apps free their stuff before they exit - i do it in all my own C apps.
> > 
> > That is generally useful: for example it makes it easier to thread a program 
> > later on - when exit() becomes pthread_exit() and a silent leak turns into a 
> > real leak.

Right, part of my goal was exactly the potential librarization of
nowaday main routines of builtin commands.

> > Hence Valgrind checking for exit() by default looks useful to me.
> 
> Sure, most of the time I would too (in fact, all the time seeing as
> I don't write non-trivial user programs). But when you're doing last
> pass optimisations, it would be very reasonable to avoid things like
> teardown of complex data structures.

Yeah, I thought about having some test to only do the on-exit
destruction of lots of rbtrees if in debugging mode, and I may end up
doing it at some point.

But on another angle, right now I think we really need to more
aggressively delete stuff (like maps that had no hits on
PERF_RECORD_EXIT'ed threads and thus have no reference on any hist_entry
instance) to support huge perf.data file buildid exit processing. So
part of the goal was that: no leaks left behind policy.

That is, till the day when we stash the 20 byte buildid in the per
binary image loaded kernel data structure so that we can have it in the
PERF_RECORD_MMAP and avoid all this processing at exit, and instead do
it taking advantage of the existing noise at loading time. 8-)

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