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]

Message-ID: <Pine.LNX.4.58.0806211058510.28481@gandalf.stny.rr.com>
Date:	Sat, 21 Jun 2008 11:07:35 -0400 (EDT)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	"Frank Ch. Eigler" <fche@...hat.com>
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


On Sat, 21 Jun 2008, Frank Ch. Eigler wrote:
> 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.

It doesn't help much if you mix a pid and prio of a task_struct, and then
use the prio to find the actual task, or try setting another task priority
to the pid.

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

I definitely want the raw pointers for my tracers, but I understand
why other tracers don't want them.  And yes I would like a compromise
here.  I'm hoping for something where I don't need to skip over the
scalers to get to the needed pointers. Things that Masami is suggesting
is looking promising.


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

The thing that those tracers need is something that can be stored in the
kernel that can easily extract the needed information.

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

I'm all for restricting this, I even suggested something similar a while
ago (http://lists.openwall.net/linux-kernel/2006/10/07/21). No, I'm not
pushing that solution, that solution was only to bring out more ideas.

>
>
> > It also just looks like a debug session instead of a trace marker.
>
> Why do you think the difference between those is profound?

Not that profound but I do find:

  trace_sched_switch(prev, next);

much nicer to look at than

  trace_mark("%p %p", prev, next);


The trace_sched_switch seems a bit more informative with a simple glance
than the trace_mark.

-- Steve

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