linux-kernel - Re: [RFC][Patch 2/2] markers: example of irq regular kernel markers

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, 21 Jun 2008 10:53:49 -0400
From:	fche@...hat.com (Frank Ch. Eigler)
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Masami Hiramatsu <mhiramat@...hat.com>,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...e.hu>,
	LKML <linux-kernel@...r.kernel.org>,
	systemtap-ml <systemtap@...rces.redhat.com>,
	Hideo AOKI <haoki@...hat.com>
Subject: Re: [RFC][Patch 2/2] markers: example of irq regular kernel markers

Steven Rostedt <rostedt@...dmis.org> writes:

> [...]  Format strings only help for printf like operations. [...]

That is not so.  They are far from panaceanic, but printf formats are
useful for type checked simple scalars, which we can extract and use
for purposes other than printf like operations.

> The best example of this is the sched_switch code. LTTng and friends
> just want a pid and comm to show. But there's tracers that want more
> info from the task_struct. We also like to see the priority of the
> task.  [...]

This is the sort of information that can help generate a compromise.
For this case, pass a few raw pointers that a compiled-in tracing
engine can dereference at will, and *also pass* a few user-level
scalars that a separately-compiled tracing engine can use.

> Passing in a pointer to the structure being traced should be enough
> for all tracers.

On the contrary, we have explained why *this is not so*.  Using raw
general structure pointers in impractical for some tracers.

> Now back to your question, why don't we like the printf
> format. Simply because it does nothing for pointers. It might help
> you with a %d and number of parameters, but a %p can not tell the
> difference between a struct tasks_struct *, and a int *, which can
> have even more devastating results.

Indeed.  Unfortunately, C is not kind to us in the way that perhaps
C++ templates could be.  We have not yet seen a single mechanism that
does all of:

- type-safe passing of arbitrary pointer/etc. types (so compiled-in
  trace data consumers can go wild with data passing)
- declarative / separately-compiled consumption of types
  (so lttng/systemtap/userspace can hook in without heroics)
- parsimonious implementation

Maybe a solution could involve some restrictions on the generalities.
For example, can we narrow down the number of different scalar +
pointer types to a fixed handful?  Can we tolerate type-safety being
provided by families of function declarations rather than one generic
one?

> It also just looks like a debug session instead of a trace marker.

Why do you think the difference between those is profound?

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