linux-kernel - Re: [PATCH 0/6] ftrace: port to the new ring

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:	Tue, 30 Sep 2008 09:45:14 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Mathieu Desnoyers <compudj@...stal.dyndns.org>
Subject: Re: [PATCH 0/6] ftrace: port to the new ring_buffer

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

> These patches are against linux-tip.
> 
> The first is just a fix in the wakeup selftest.
> 
> The next is a port of the Unified tracer buffer to linux-tip and some 
> updates.
> 
> After that is the ftrace port to use the ring buffer, followed by some 
> more enhancements to ftrace because of the new variable length buffer.
> 
> I tried a few configurations and tried to test all the different 
> ftrace tracers, but I'm sure there may be some bugs still to work out. 
> I worked out all those that I found.

very nice! I'd expect breakages and complications too so i restructured 
tip/tracing/* a bit: firstly i created a tip/tracing/core append-only 
merge branch which collects all the known-robust bits. Then i created a 
new branch for your new generic ring-buffer feature: 
tip/tracing/ring-buffer, and applied your patches. I've started testing 
it.

Once we declare it OK, it can be merged into tip/tracing/core.

> But, with the ring_buffer I can envision several ways to clean up 
> ftrace and to make adding new tracers cleaner.
> 
> I'm also thinking about making a way that each tracer can allocate its 
> own buffer, and allow for more than one tracer to be running at the 
> same time! (only with different buffers).

yeah. Ideally this should just fall out of the generic framework - i.e. 
tracer plugins should not have to do anything extra to get per tracer 
buffers. They should just add their own specialistic flavor, there 
should be no repetitions otherwise. (barring cases where a tracer wants 
to deviate from default behavior)

	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/