linux-kernel - Re: [PATCH] perf: do not flush maps on COMM for perf report

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: <20120822162958.GA13623@infradead.org>
Date:	Wed, 22 Aug 2012 13:29:58 -0300
From:	Arnaldo Carvalho de Melo <acme@...stprotocols.net>
To:	Luigi Semenzato <semenzato@...omium.org>
Cc:	Ingo Molnar <mingo@...nel.org>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Paul Mackerras <paulus@...ba.org>, Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Vasiliy Kulikov <segoon@...nwall.com>,
	Stephen Wilson <wilsons@...rt.ca>,
	Oleg Nesterov <oleg@...hat.com>, Tejun Heo <tj@...nel.org>,
	Paul Gortmaker <paul.gortmaker@...driver.com>,
	Andi Kleen <ak@...ux.intel.com>,
	Lucas De Marchi <lucas.demarchi@...fusion.mobi>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Frederic Weisbecker <fweisbec@...il.com>,
	David Ahern <dsahern@...il.com>,
	Namhyung Kim <namhyung@...il.com>,
	Robert Richter <robert.richter@....com>,
	linux-kernel@...r.kernel.org, sonnyrao@...omium.org,
	olofj@...omium.org, eranian@...gle.com
Subject: Re: [PATCH] perf: do not flush maps on COMM for perf report

Em Wed, Aug 22, 2012 at 09:09:10AM -0700, Luigi Semenzato escreveu:
> On Wed, Aug 22, 2012 at 12:28 AM, Ingo Molnar <mingo@...nel.org> wrote:
> > * Luigi Semenzato <semenzato@...omium.org> wrote:
> >> An alternative patch (which I proposed earlier) would be to
> >> introduce a separate PERF_RECORD_EXEC type, but it is a much
> >> larger change (about 300 lines) and is not necessary.

> > It would be nice to add that too - we already have FORK/EXIT,
> > this seems like a natural extension.

> Yes.  Adding PERF_RECORD_EXEC is/would be the right long-term
> solution.  But there are two issues.

> 1. One nice aspect of perf is that perf.data files and "perf report"
> are compatible across a large number of versions.  Adding
> PERF_RECORD_EXEC breaks compatibility in a somewhat unpleasant manner.
>  New perf.data files won't work with old versions of perf and *might*
> fail poorly (segv) although this situation is difficult to analyze.

> 2. Adding a new record type is messy.  It replicates a lot of
> boilerplate code, much of it in the kernel, and affects many parts of
> the system.  It adds to size, complexity, and likelihood of new bugs.

> I would prioritize the "would be nice" category as follows.

> 1. Improve the handling of unknown record types for future better
> backward compatibility.  (Small change.)

> 2. Refactor/cleanup code to improve readability and robustness.  (Big
> change, but can be broken into many smaller pieces.)

> 3. Add PERF_RECORD_EXEC.

> If there is consensus, I might be able to give a shot to 1 and 2
> (courtesy of Google).

I think this is just common sense, i.e. I'd love to take patches that
improve the robustness of the tools any day.

Refactoring code to make it cleaner and possibly faster and/or smaller,
ditto.

Adding the EXEC event, ditto. And I agree that while adding it we want
to do 1/2 as pre-requisite.

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