linux-kernel - Re: [PATCH] ftrace: add an fsync tracer

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: <20081106222529.GA17528@Krystal>
Date:	Thu, 6 Nov 2008 17:25:29 -0500
From:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
To:	"Frank Ch. Eigler" <fche@...hat.com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	linux-kernel@...r.kernel.org, mingo@...e.hu, alan@...hat.com,
	jbaron@...hat.com
Subject: Re: [PATCH] ftrace: add an fsync tracer

* Frank Ch. Eigler (fche@...hat.com) wrote:
> Hi -
> 
> On Thu, Nov 06, 2008 at 04:53:11PM -0500, Mathieu Desnoyers wrote:
> > [...]
> > > Something like
> > > 
> > > DEFINE_TRACE_FMT(sched_switch,
> > > 	TPPROTO(struct rq *rq, struct task_struct *prev,
> > > 		 struct task_struct *next),
> > > 	TPARGS(rq, prev, next),
> > > 	TPFMT("%d to %d\n", prev->pid, next->pid));
> > > 
> > > Which would be similar to attaching a trace_mark() to the trace point
> > > and can in these cases save a lot of lines of code.
> > > 
> > > Both lttng and the ftrace event tracer can use these default text
> > > strings.
> > 
> > Argh. No, please. Doing this would end up exposing the inner kernel API
> > (the tracepoints) directly to userspace. [...]
> 
> 
> Arjan asked for something to send formatted strings to tracing buffers
> that are consumed by user space.  Whether internally that is done by
> markers, or by tracepoints converted to markers, or by tracepoints
> with custom ftrace_printf-y code, is indistinguishable to the user.
> 
> Can you be specific in what way any of that is exposing an "API
> directly to userspace"?
> 
> - FChE

The tracepoint declaration is linked to the kernel code that is meant to
be traced. Given this code will change over time, it will be more
difficult to perform those changes if it is in any way coupled with
format strings exported to userspace via traced.

This is where using the markers as an indirection layer plays its role.

I also have a patch with "redux" markers, where I separate the marker
"declaration" from the marker "call". By doing this, I remove the need
for cascading function calls, which is more efficient.

Mathieu


-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
--
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/