linux-kernel - Re: Kernel marker has no performance impact on ia64.

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, 12 Jun 2008 18:53:41 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	"Frank Ch. Eigler" <fche@...hat.com>
Cc:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	Hideo AOKI <haoki@...hat.com>, mingo@...e.hu,
	Masami Hiramatsu <mhiramat@...hat.com>,
	linux-kernel@...r.kernel.org, Steven Rostedt <rostedt@...dmis.org>
Subject: Re: Kernel marker has no performance impact on ia64.

On Thu, 2008-06-12 at 11:53 -0400, Frank Ch. Eigler wrote:
> Hi -
> 
> On Thu, Jun 12, 2008 at 04:27:03PM +0200, Peter Zijlstra wrote:
> > [...]
> > > Well, the string contains each field name and type. Therefore, SystemTAP
> > > can hook on a marker and parse the string looking for some elements by
> > > passing a NULL format string upon probe registration. Alternatively, it
> > > can provide the exact format string expected when it registers its probe
> > > to the marker and a check will be done to verify that the format string
> > > passed along with the registered probe matches the marker format string.
> > 
> > Yes, I get that, its one of the ugliest things I've met in this whole
> > marker story. Why can't stap not insert a normal trace handler that
> > extracts the information from prev/next it wants? [...]
> 
> Think this through.  How should systemtap (or another user-space
> separate-compiled tool like lttng) do this exactly?

lttng has trace handlers to write data into some buffer, right?
The trace point need not be concerned with which data, nor into what
buffer.

> (a) rely on debugging information?  Even assuming we could get proper
>     anchors (PC addresses or unambiguous type names) to start
>     searching dwarf data, we lose a key attractions of markers: that
>     it can robustly transfer data *without* dwarf data kept around.

Perhaps you can ship a reduced set of dwarf info tailored to contain the
bits you need, like where to find ->pid in struct task_struct. Or you
can hook into the lttng tracer.

> (b) rely on hand-written C code (prototypes, pointer derefrencing
>     wrappers) distributed with systemtap?  Not only would this be a
>     brittle maintenance pain in the form of cude duplication, but then
>     errors in it couldn't even be detected until the final C
>     compilation stage.  That would make a lousy user experience.

Not really sure what you mean here - I throught compile time errors were
the goal?!

> (c) have systemtap try to parse the mhiramat-proposed "(struct
>     task_struct * next, struct task_struct * prev)" format strings?
>     Then we're asking systemtap to parse potentially general C type
>     expressions, find the kernel headers that declare the types?
>     Parse available subfields?  That seems too much to ask for.

tcc and sourcefs sound like way fun ;-)

> (d) or another way?

Get your own tracer in kernel - that provides exactly what stap needs?


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