linux-kernel - Re: [PATCH 2/3] ftrace: add ftrace-buffer option

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:	Mon, 2 Nov 2015 18:12:15 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc:	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH 2/3] ftrace: add ftrace-buffer option

On Mon, 2 Nov 2015 23:01:08 +0000 (UTC)
Mathieu Desnoyers <mathieu.desnoyers@...icios.com> wrote:

> ----- On Nov 2, 2015, at 5:56 PM, rostedt rostedt@...dmis.org wrote:
> 
> > On Mon,  2 Nov 2015 17:42:43 -0500
> > Mathieu Desnoyers <mathieu.desnoyers@...icios.com> wrote:
> > 
> >> In order to use ftrace tracers to generate tracepoints without doing
> >> tracing to its own hardcoded ring buffers, add a ftrace-buffer option
> >> (default: 1). When set to 0, it disables tracing into the ftrace
> >> hardcoded buffers.
> >> 
> > 
> > This needs a more in depth change log. I have no idea why this is
> > needed.
> 
> I can do an updated change log. This is needed for the next patch
> in this series, which adds tracepoints in the ftrace irqs and preempt
> off tracer, so other tracers such as Perf and LTTng can use them.
> 
> > 
> > Also, the trace_options code have been redesigned, and this won't apply
> > to it (see linux-next).
> 
> I can rebase my work on top of linux-next if you are OK with
> the general idea.
> 
> > Also, if this is only for irqsoff latency
> > tracers, it should be a tracer option, not a global one.
> 
> I've currently only done the irqsoff latency tracer
> part, but I'm wondering whether:
> 
> 1- we should make it a irqsoff latency tracer option,
> 2- we should keep it as a global ftrace option, and apply it to
>    other ftrace tracers as well,
> 
> Thoughts ?
> 
>

Tomorrow I'll take a deeper look at patch 3 to try to understand.

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