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
| ||
|
Date: Wed, 17 Nov 2010 10:10:34 -0500 From: Steven Rostedt <rostedt@...dmis.org> To: Peter Zijlstra <peterz@...radead.org> Cc: Ingo Molnar <mingo@...e.hu>, Ted Ts'o <tytso@....edu>, Thomas Gleixner <tglx@...utronix.de>, LKML <linux-kernel@...r.kernel.org>, Linus Torvalds <torvalds@...ux-foundation.org>, Andrew Morton <akpm@...ux-foundation.org>, Arjan van de Ven <arjan@...radead.org>, Arnaldo Carvalho de Melo <acme@...hat.com>, Frederic Weisbecker <fweisbec@...il.com>, Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>, Tom Zanussi <tzanussi@...il.com>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, Li Zefan <lizf@...fujitsu.com>, Jason Baron <jbaron@...hat.com>, "David S. Miller" <davem@...emloft.net>, Christoph Hellwig <hch@....de>, Pekka Enberg <penberg@...nel.org>, Lai Jiangshan <laijs@...fujitsu.com>, Eric Dumazet <eric.dumazet@...il.com> Subject: Re: [ANNOUNCE] New utility: 'trace' On Wed, 2010-11-17 at 15:11 +0100, Peter Zijlstra wrote: > On Wed, 2010-11-17 at 15:00 +0100, Ingo Molnar wrote: > > > But yes, it is functional. > > > > I suspect that is what matters mostly - unless you think that it's impossible to > > have a sane implementation of it, if the users come. > > I'm not sure, I raised the point several times, and I think Steve and > Tom though it was possible to implement sanely, but I'm not sure if it > was expression invariant (the fix that is). > > It would be very good to have a definite answer on that. > > The idea was to not let the filter engine work on the trace data (once > its gathered) but on the trace argument right at the beginning of the > tracepoint callchain, since some of the trace data is an expression of > the trace argument (say next->prio instead of next), the trace > expression wouldn't stay invariant, you'd have to write a different > filter for the same effect. > > So I think it would be wise to make this change sooner rather than > later. Right, the problem with filtering is what do we want to filter, and what about copying? Currently, we copy the data into the buffer and then filter on that data. We could also easily filter on the parameters of the tracepoint, but sometimes those parameters do not match the final output (as the case with sched_switch). Do we copy the data into a separate "per cpu" temp buffer, and figure out the filter then? And if the filter is fine, then copy into the buffer. This obviously is slow, due to the multiple copies. We could do this only if the filtering is enabled. Note, the stable event proposal I suggested passes the same info via the trace callback parameters that is expected to go into the buffer. Arrays are passed as pointers so the copying is of the minimum. This would give us the ability to filter _before_ writing into the buffer, and no unnecessary copying. -- 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/
Powered by blists - more mailing lists