linux-kernel - Re: [RFC PATCH 3/4] trace: Duplicate the output of the function trace logs to STM

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: <CAG2=9p9w5qR1FH5evBu19Wp9YUJbFDvLnFpOp4PZNqZZTVJoTA@mail.gmail.com>
Date:	Wed, 8 Jun 2016 19:02:13 +0800
From:	Chunyan Zhang <zhang.chunyan@...aro.org>
To:	Alexander Shishkin <alexander.shishkin@...ux.intel.com>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	Mathieu Poirier <mathieu.poirier@...aro.org>, mingo@...hat.com,
	Mike Leach <mike.leach@....com>, Tor Jeremiassen <tor@...com>,
	Maxime Coquelin <maxime.coquelin@...com>,
	philippe.langlais@...com, Nicolas GUION <nicolas.guion@...com>,
	Lyra Zhang <zhang.lyra@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC PATCH 3/4] trace: Duplicate the output of the function trace
 logs to STM

On Tue, Jun 7, 2016 at 6:00 PM, Alexander Shishkin
<alexander.shishkin@...ux.intel.com> wrote:
> 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"?

Sorry if this is ambiguously expression, I mean the buffer which
stores the trace data from STM, such as ETB/TMC for CoreSight.

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

Yes, only knowing function pointers may not be very useful, if doing
in this way is acceptable I intend to add more interfaces to export
more information to STM in the feature, I will appreciate if you can
tell me what information you think is _absolutely_ necessary.

Thanks,
Chunyan

>
> Regards,
> --
> Alex