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 11:53:32 -0400
From:	"Frank Ch. Eigler" <fche@...hat.com>
To:	Peter Zijlstra <peterz@...radead.org>
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.

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?

(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.

(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.

(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.

(d) or another way?


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