Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Subject: Re: [PATCH v2 3/9] LoongArch/ftrace: Add dynamic function tracer
 support
To:     Jeff Xie <xiehuan09@gmail.com>
Cc:     Huacai Chen <chenhuacai@kernel.org>,
        Steven Rostedt <rostedt@goodmis.org>,
        Ingo Molnar <mingo@redhat.com>,
        WANG Xuerui <kernel@xen0n.name>, loongarch@lists.linux.dev,
        linux-kernel@vger.kernel.org,
        Jiaxun Yang <jiaxun.yang@flygoat.com>, hejinyang@loongson.cn
References: <20220826073114.1515-1-zhangqing@loongson.cn>
 <20220826073114.1515-4-zhangqing@loongson.cn>
 <CAEr6+EC9vtsPmj5f+b5iqJWOGyC7D5g+mpv01_ekzA9gQjgeAg@mail.gmail.com>
From:   Qing Zhang <zhangqing@loongson.cn>
Message-ID: <374ddd54-4c04-65cc-4097-c7a145c2c029@loongson.cn>
Date:   Sat, 3 Sep 2022 08:38:59 +0800
User-Agent: Mozilla/5.0 (X11; Linux mips64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <CAEr6+EC9vtsPmj5f+b5iqJWOGyC7D5g+mpv01_ekzA9gQjgeAg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk


On 2022/9/1 上午10:59, Jeff Xie wrote:
> On Fri, Aug 26, 2022 at 4:24 PM Qing Zhang <zhangqing@loongson.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

>