linux-kernel - Re: [PATCH v2 3/9] LoongArch/ftrace: Add dynamic function tracer support

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] [day] [month] [year] [list]

Message-ID: <374ddd54-4c04-65cc-4097-c7a145c2c029@loongson.cn>
Date:   Sat, 3 Sep 2022 08:38:59 +0800
From:   Qing Zhang <zhangqing@...ngson.cn>
To:     Jeff Xie <xiehuan09@...il.com>
Cc:     Huacai Chen <chenhuacai@...nel.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Ingo Molnar <mingo@...hat.com>,
        WANG Xuerui <kernel@...0n.name>, loongarch@...ts.linux.dev,
        linux-kernel@...r.kernel.org,
        Jiaxun Yang <jiaxun.yang@...goat.com>, hejinyang@...ngson.cn
Subject: Re: [PATCH v2 3/9] LoongArch/ftrace: Add dynamic function tracer
 support



On 2022/9/1 上午10:59, Jeff Xie wrote:
> On Fri, Aug 26, 2022 at 4:24 PM Qing Zhang <zhangqing@...ngson.cn> wrote:
>>
>> The compiler has inserted 2 NOPs before the regular function prologue.
>> T series registers are available and safe because of LoongArch psABI.
>>
>> At runtime, replace nop with bl to enable ftrace call and replace bl with
>> nop to disable ftrace call. The bl requires us to save the original RA value,
>> so here it saves RA at t0.
>> details are:
>>
>> | Compiled   |       Disabled         |        Enabled         |
>> +------------+------------------------+------------------------+
>> | nop        | move     t0, ra        | move     t0, ra        |
>> | nop        | nop                    | bl      ftrace_caller  |
>> | func_body  | func_body              | func_body              |
>>
>> The RA value will be recovered by ftrace_regs_entry, and restored into RA
>> before returning to the regular function prologue. When a function is not
>> being traced, the move t0, ra is not harmful.
>>
>> 1) ftrace_make_call, ftrace_make_nop (in kernel/ftrace.c)
>>     The two functions turn each recorded call site of filtered functions
>>     into a call to ftrace_caller or nops.
>>
>> 2) ftracce_update_ftrace_func (in kernel/ftrace.c)
>>     turns the nops at ftrace_call into a call to a generic entry for
>>     function tracers.
>>
>> 3) ftrace_caller (in kernel/mcount-dyn.S)
>>     The entry where each _mcount call sites calls to once they are
>>     filtered to be traced.
>>
[...]
>>
> 
> When use the option func_stack_trace for the function tracer, I found a issue:
> 
> Steps:
> 1. Enable the function tracer and the option func_stack_trace:
> 
> /sys/kernel/tracing # echo blk_update_request > ./set_ftrace_filter
> /sys/kernel/tracing # echo 1 > ./options/func_stack_trace
> /sys/kernel/tracing # echo function > ./current_tracer
> 
> 2. Let the blk_update_request() be called.
> 
>   # mount /dev/vda /tmp
> 
> 
> 3. cat ./trace
>            <idle>-0       [000] ..s1.   126.016445: blk_update_request
> <-blk_mq_end_request
>            <idle>-0       [000] ..s1.   126.017937: <stack trace>
>   => blk_mq_end_request
> 
> We can see only one stack trace.
> 
> 
> I found the default unwinder(for loongson3_defconfig) is
> CONFIG_UNWINDER_PROLOGUE, if switch it to CONFIG_UNWINDER_GUESS
> it works well:
> 
[...]
> 
> Maybe the issue happened on the CONFIG_UNWINDER_PROLOGUE,  but I
> haven't dug deep into it ;)

Hi, Jeff

Thanks a lot for your feedback!

I fixed it in v3, which was caused by the ftrace_regs_entry assembly not 
being considered by the prologue analyze method. :)

regards
-Qing

>