linux-kernel - Re: [PATCH] tracing/filters: add TRACE_EVENT_FORMAT

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] [day] [month] [year] [list]

Message-ID: <20090912202422.GF4961@nowhere>
Date:	Sat, 12 Sep 2009 22:24:24 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>, Tom Zanussi <tzanussi@...il.com>
Subject: Re: [PATCH] tracing/filters: add TRACE_EVENT_FORMAT_NOFILTER event
	macro

On Sat, Sep 12, 2009 at 03:56:52PM -0400, Steven Rostedt wrote:
> On Tue, 2009-03-31 at 00:49 -0500, Tom Zanussi wrote:
> > Frederic Weisbecker suggested that the trace_special event shouldn't be
> > filterable; this patch adds a TRACE_EVENT_FORMAT_NOFILTER event macro
> > that allows an event format to be exported without having a filter
> > attached, and removes filtering from the trace_special event.
> > 
> 
> Frederic,
> 
> Do you remember why trace_special should not be filtered? I think
> earlier we use to use it for lots of special markings, but now that we
> have trace_printk, at least I have not used it in a long time.
> 
> Reason why I'm asking, is that I've wrote a patch that automates the
> format of the debugfs/tracing/events/ftrace/* files. I'm using macros
> like we have in include/trace/events/ to create the ftrace internal
> structures. This way we get rid of the manual exporting of that
> directory and now the formats will be automatically match the ring
> buffer internals.
> 
> This also adds some entries that were not ported, just because it is
> automated we get all of them. I'm thinking it would be more powerful to
> let all ftrace entries be filtered. Even the trace_printks.
> 
> What do you think?
> 
> -- Steve



It's not that it would harm but it would be meaningless.
The tracer that uses the special entry is the only one
that can give sense to it.

Sysprof is the only user IIRC.

If I'm not wrong, the first field gives the sense of the other fields:

0 -> pid
1 -> backtrace node
2 -> backtrace node (userland)
3 -> backtrace overflow

Well, actually while thinking more about it, we may want to
filter with "arg0 == 1 && arg1 == addr_to_filter_in_a_callchain" or things like
that.

So I guess actually that could be useful.
I did not think about it at that time...

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