linux-kernel - Re: [PATCH 2/5] perf events: Default to using event__process

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]

Date:	Sat, 27 Nov 2010 00:55:24 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Arnaldo Carvalho de Melo <acme@...radead.org>
cc:	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Mike Galbraith <efault@....de>,
	Paul Mackerras <paulus@...ba.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Stephane Eranian <eranian@...gle.com>,
	Tom Zanussi <tzanussi@...il.com>
Subject: Re: [PATCH 2/5] perf events: Default to using event__process_lost

On Fri, 26 Nov 2010, Arnaldo Carvalho de Melo wrote:

> From: Arnaldo Carvalho de Melo <acme@...hat.com>
> 
> Tool developers have to fill in a 'perf_event_ops' method table to
> specify how to handle each event, so far the ones that were not
> explicitely especified would get a stub that would just discard the
> event.
> 
> Change that so that tool developers can get the lost event details and
> the total number of such events at the end of 'perf report -D' output.

That should be always displayed if the subcommand does not have it's
own lost event handling. I stared long enough into the wrong place,
just because the stupid thing just was silent about it. And with this
patch it's still silent for the normal use case.

We really want to tell the user when something went wrong. Users do
not run perf report -D when the tool shows fancy events, why should
they? Just because they know that the tool is hiding problems? If
that's the case then the trust into perf tools is about 0.

Darn, being silent about a known problem is the most stupid error
handling ever.

That's what I added at the end of perf_session__process_events()

+	if (self->hists.stats.total_lost)
+		fprintf(stderr, "Lost events. Check IO/CPU overload!\n");

It's hacky, but it does the job and tells me clearly that the trace is
only halfways useful.

There are only two files, which implement their own lost handling:
builtin-inject.c and builtin-script.c

So everything else looks at incomplete data and let's the user wonder
about the resulting crap in the output.

Thanks,

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