linux-kernel - Re: [PATCH] new irq tracer

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:	Thu, 19 Feb 2009 00:21:38 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	"Frank Ch. Eigler" <fche@...hat.com>
Cc:	Jason Baron <jbaron@...hat.com>, mingo@...e.hu,
	rostedt@...dmis.org, linux-kernel@...r.kernel.org,
	acme@...stprotocols.net, fweisbec@...il.com,
	compudj@...stal.dyndns.org
Subject: Re: [PATCH] new irq tracer

On Wed, 2009-02-18 at 17:23 -0500, Frank Ch. Eigler wrote:
> Hi -
> 
> On Wed, Feb 18, 2009 at 11:10:35PM +0100, Peter Zijlstra wrote:
> > > > I really am having a difficult time seeing the use in such narrow
> > > > tracers.
> > > 
> > > Part of the problem may come from defining "tracers" as something
> > > limited to ftrace engines.  Once such tracepoints are in the kernel,
> > > more powerful analytical tools may be attached to them.
> > 
> > ftrace graph tracer is by far the most powerful thing I've seen [...]
> 
> Be that as it may, what you suggested required separate correlation of
> data with /proc/interrupts contents.

That was to illustrate that the proposed tracer doesn't add much value.
Its almost 200 lines of code that needs maintenance to provide
information that's mostly already available, seems like the wrong
tradeoff to me.

> > What is limiting are these puny little tracers that have no real value.
> 
> Which limited resource would even puny tracers exhaust?

Usability and maintenance. But loss of the bigger picture is the main
complaint.

> > A much better purpose for these tracepoints would be augmenting data in
> > existing tracers like the graph/function/sched tracer.
> 
> Be more specific.  How would you augment those tracers with e.g.
> individual irq numbers, their disposition status (HANDLED etc.).

With a mixture of creativity and code ;-)

Perhaps by creating a way to provide argument and return values to the
function call data, and registering tracepoints to obtain these.

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