linux-kernel - Re: [RFC PATCH 2/5] tracing/events: nicer print format for parsing

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:	Wed, 10 Jun 2009 19:16:48 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Minchan Kim <minchan.kim@...il.com>,
	Mel Gorman <mel@....ul.ie>, Rik van Riel <riel@...hat.com>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Peter Zijlstra <peterz@...radead.org>,
	Theodore Tso <tytso@....edu>,
	Mathieu Desnoyers <compudj@...stal.dyndns.org>,
	Lai Jiangshan <laijs@...fujitsu.com>,
	Zhaolei <zhaolei@...fujitsu.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Jason Baron <jbaron@...hat.com>,
	Jiaying Zhang <jiayingz@...gle.com>
Subject: Re: [RFC PATCH 2/5] tracing/events: nicer print format for parsing


* Steven Rostedt <rostedt@...dmis.org> wrote:

> 
> On Wed, 10 Jun 2009, Ingo Molnar wrote:
> > 
> > And i kind of like the whole notion on a design level as weell: the 
> > kernel exporting C source code for tools :-)
> > 
> > 	Ingo
> > 
> > ------------------>
> > 
> > struct record {
> > 	unsigned short common_type;
> > 	unsigned char common_flags;
> > 	unsigned char common_preempt;
> > 	int common_pid;
> > 	int common_tgid;
> > 	int dev;
> > 	unsigned long long sector;
> > 	unsigned int nr_sector;
> > 	char rwbs[6];
> > 	char comm[16];
> > } this_record = { 1, 2, 3, 4, 5, 6, 7, 8, { 'a', }, "abc" };
> > 
> > void main(void)
> > {
> > 	struct record *REC = &this_record;
> > 
> > 	printf("%d,%d %s %llu + %u [%s]", ((unsigned int) ((REC->dev) >> 20)), ((unsigned int) ((REC->dev) & ((1U << 20) - 1))), REC->rwbs, (unsigned long long)REC->sector, REC->nr_sector, REC->comm);
> > }
> 
> I actually tried this first. But it breaks once we start getting types 
> into the code:
> 
> print fmt: "call_site=%lx ptr=%p bytes_req=%zu bytes_alloc=%zu gfp_flags=%s",
>           REC->call_site, REC->ptr, REC->bytes_req, REC->bytes_alloc, 
>           (REC->gfp_flags) ? ({ static const struct trace_print_flags 
>           flags[] = { {(unsigned long)(((gfp_t)0x10u) | ((gfp_t)0x40u) |
>                       ((gfp_t)0x80u) | ((gfp_t)0x20000u) | ((gfp_t)0x02u) | 
>                        ((gfp_t)0x100000u)), "GFP_HIGHUSER_MOVABLE"}, [...]
> 
> Will break on gfp_t. [...]

It wont break if we introduce a couple of common-sense types into 
the parsing/translation code. gfp_t is well-known.

Modules wont be able to generate new dynamic types - but that's OK i 
think, existing C types and common kernel types (and anything else 
we add) ought to be plenty enough.

> [...] We also have cases where the enum name slips in too:
> 
> print fmt: "softirq=%d action=%s", REC->vec, ({ static const struct trace_print_flags symbols[] =
>             { { HI_SOFTIRQ, "HI" }, { TIMER_SOFTIRQ, "TIMER" }, { NET_TX_SOFTIRQ, "NET_TX" },
>               { NET_RX_SOFTIRQ, "NET_RX" }, { BLOCK_SOFTIRQ, "BLOCK" },
>               { TASKLET_SOFTIRQ, "TASKLET" }, { SCHED_SOFTIRQ, "SCHED" },
>               { HRTIMER_SOFTIRQ, "HRTIMER" }, { RCU_SOFTIRQ, "RCU" },
>               { -1, ((void *)0) }}; ftrace_print_symbols_seq(p, REC->vec, symbols); })
> 
> Yes we can add special types for things like gfp_t, but as we get 
> more and more users of TRACE_EVENT, the tools will never be able 
> to keep up.

i still disagree. The tool will have to know about gfp_t in the tag 
language too. So there's always going to be a constant expansion of 
the type space.

The point is that the number of new types is an order of magnitude 
less than the number of new tracepoints.

Also, with tools like perf in the kernel repo under tools/perf/, 
we'll be able to keep up with mainline types very flexibly and very 
accurately.

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