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: <CAAfSe-uZK0X41rMrSsHPCgssjN9dty43VxsyVtX1Hd01FgJ77w@mail.gmail.com>
Date:   Mon, 20 Mar 2017 18:58:14 +0800
From:   Chunyan Zhang <zhang.lyra@...il.com>
To:     Alexander Shishkin <alexander.shishkin@...ux.intel.com>
Cc:     Chunyan Zhang <chunyan.zhang@...eadtrum.com>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Mathieu Poirier <mathieu.poirier@...aro.org>,
        nicolas.guion@...com
Subject: Re: [PATCH] stm class: Document the stm_ftrace

Hi Alex,

On 20 March 2017 at 16:49, Alexander Shishkin
<alexander.shishkin@...ux.intel.com> wrote:
> Hi Chunyan,
>
> A couple of clarifications: iirc this applies to the function tracer
> of ftrace, right? Does it make sense to mention that? Also, are you

Right, only applies to the function tracer currently (actually only
function address and parent function address of Function tracer is
recorded into STM, I mean it doesn't include like "pid" "task name"
"cpu-id" these information right now). It makes sense to mention
function tracer, I will address that.

> planning to support other ftrace payloads like trace_printk()s?

No plan so far, but I think I can consider to do that, it depends on
how many people think that are helpful.
What do you think?

Thanks,
Chunyan

>
> Thanks,
> --
> Alex
>
> On 20 March 2017 at 08:47, Chunyan Zhang <chunyan.zhang@...eadtrum.com> wrote:
>> This patch adds a description of the stm_ftrace device source, an
>> interface for collecting Function trace information via STM devices.
>>
>> Signed-off-by: Chunyan Zhang <chunyan.zhang@...eadtrum.com>
>> ---
>>  Documentation/trace/stm.txt | 10 +++++++++-
>>  1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/trace/stm.txt b/Documentation/trace/stm.txt
>> index 11cff47..7ec1c0e 100644
>> --- a/Documentation/trace/stm.txt
>> +++ b/Documentation/trace/stm.txt
>> @@ -83,7 +83,7 @@ by writing the name of the desired stm device there, for example:
>>  $ echo dummy_stm.0 > /sys/class/stm_source/console/stm_source_link
>>
>>  For examples on how to use stm_source interface in the kernel, refer
>> -to stm_console or stm_heartbeat drivers.
>> +to stm_console, stm_heartbeat or stm_ftrace drivers.
>>
>>  Each stm_source device will need to assume a master and a range of
>>  channels, depending on how many channels it requires. These are
>> @@ -107,5 +107,13 @@ console in the STP stream, create a "console" policy entry (see the
>>  beginning of this text on how to do that). When initialized, it will
>>  consume one channel.
>>
>> +stm_ftrace
>> +==========
>> +
>> +This is another "stm_source" device, once the stm_ftrace is linked with
>> +an stm device, function address and parent function address which
>> +Ftrace subsystem would store into ring buffer will be exported via the
>> +stm device at the same time.
>> +
>>  [1] https://software.intel.com/sites/default/files/managed/d3/3c/intel-th-developer-manual.pdf
>>  [2] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0444b/index.html
>> --
>> 2.7.4
>>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ