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: <87lh2hqpxm.fsf@ashishki-desk.ger.corp.intel.com>
Date:	Tue, 07 Jun 2016 13:00:21 +0300
From:	Alexander Shishkin <alexander.shishkin@...ux.intel.com>
To:	Chunyan Zhang <zhang.chunyan@...aro.org>, rostedt@...dmis.org,
	mathieu.poirier@...aro.org, mingo@...hat.com
Cc:	mike.leach@....com, tor@...com, maxime.coquelin@...com,
	philippe.langlais@...com, nicolas.guion@...com,
	zhang.lyra@...il.com, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFC PATCH 3/4] trace: Duplicate the output of the function trace logs to STM

Chunyan Zhang <zhang.chunyan@...aro.org> writes:

> This patch adds an output from Ftrace to STM.

But does it?

> That being said,
> Function trace messages would also be duplicated to STM buffer when
> being stored into ring buffer.

Not sure what you mean here. What's "STM buffer"?

>
> Signed-off-by: Chunyan Zhang <zhang.chunyan@...aro.org>
> ---
>  kernel/trace/trace.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 8a4bd6b..d613053 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -44,6 +44,7 @@
>  
>  #include "trace.h"
>  #include "trace_output.h"
> +#include "trace_output_stm.h"
>  
>  /*
>   * On boot up, the ring buffer is set to the minimum size, so that
> @@ -1884,8 +1885,10 @@ trace_function(struct trace_array *tr,
>  	entry->ip			= ip;
>  	entry->parent_ip		= parent_ip;
>  
> -	if (!call_filter_check_discard(call, entry, buffer, event))
> +	if (!call_filter_check_discard(call, entry, buffer, event)) {
>  		__buffer_unlock_commit(buffer, event);
> +		ftrace_stm_func(ip, parent_ip);
> +	}

So this logs instruction pointers, not the actual events. Not much is
duplicated like the message suggests, but it also doesn't seem very
useful.

Regards,
--
Alex

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ