All of lore.kernel.org
 help / color / mirror / Atom feed
From: Xu Kuohai <xukuohai@huawei.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: <bpf@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <netdev@vger.kernel.org>,
	<linux-kselftest@vger.kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Ingo Molnar <mingo@redhat.com>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Alexei Starovoitov <ast@kernel.org>,
	Zi Shen Lim <zlim.lnx@gmail.com>,
	Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
	Yonghong Song <yhs@fb.com>,
	John Fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@kernel.org>,
	"David S . Miller" <davem@davemloft.net>,
	Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
	David Ahern <dsahern@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>, <x86@kernel.org>,
	<hpa@zytor.com>, Shuah Khan <shuah@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Ard Biesheuvel <ardb@kernel.org>,
	Pasha Tatashin <pasha.tatashin@soleen.com>,
	Peter Collingbourne <pcc@google.com>,
	Daniel Kiss <daniel.kiss@arm.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Steven Price <steven.price@arm.com>,
	Marc Zyngier <maz@kernel.org>, Mark Brown <broonie@kernel.org>,
	Kumar Kartikeya Dwivedi <memxor@gmail.com>,
	Delyan Kratunov <delyank@fb.com>
Subject: Re: [PATCH bpf-next v2 2/6] ftrace: Fix deadloop caused by direct call in ftrace selftest
Date: Thu, 21 Apr 2022 11:01:49 +0800	[thread overview]
Message-ID: <0c8976f2-c2d9-8f32-3d2a-725c060fc7e9@huawei.com> (raw)
In-Reply-To: <20220420192405.4e43a966@gandalf.local.home>

On 4/21/2022 7:24 AM, Steven Rostedt wrote:
> On Thu, 14 Apr 2022 12:22:16 -0400
> Xu Kuohai <xukuohai@huawei.com> wrote:
> 
>> After direct call is enabled for arm64, ftrace selftest enters a
>> dead loop:
>>
>> <trace_selftest_dynamic_test_func>:
>> 00  bti     c
>> 01  mov     x9, x30                            <trace_direct_tramp>:
>> 02  bl      <trace_direct_tramp>    ---------->     ret
>>                                                      |
>>                                          lr/x30 is 03, return to 03
>>                                                      |
>> 03  mov     w0, #0x0   <-----------------------------|
>>      |                                               |
>>      |                   dead loop!                  |
>>      |                                               |
>> 04  ret   ---- lr/x30 is still 03, go back to 03 ----|
>>
>> The reason is that when the direct caller trace_direct_tramp() returns
>> to the patched function trace_selftest_dynamic_test_func(), lr is still
>> the address after the instrumented instruction in the patched function,
>> so when the patched function exits, it returns to itself!
>>
>> To fix this issue, we need to restore lr before trace_direct_tramp()
>> exits, so make trace_direct_tramp() a weak symbol and rewrite it for
>> arm64.
>>
>> To detect this issue directly, call DYN_FTRACE_TEST_NAME() before
>> register_ftrace_graph().
>>
>> Reported-by: Li Huafei <lihuafei1@huawei.com>
>> Signed-off-by: Xu Kuohai <xukuohai@huawei.com>
>> ---
>>  arch/arm64/kernel/entry-ftrace.S | 10 ++++++++++
>>  kernel/trace/trace_selftest.c    |  4 +++-
>>  2 files changed, 13 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/kernel/entry-ftrace.S b/arch/arm64/kernel/entry-ftrace.S
>> index dfe62c55e3a2..e58eb06ec9b2 100644
>> --- a/arch/arm64/kernel/entry-ftrace.S
>> +++ b/arch/arm64/kernel/entry-ftrace.S
>> @@ -357,3 +357,13 @@ SYM_CODE_START(return_to_handler)
>>  	ret
>>  SYM_CODE_END(return_to_handler)
>>  #endif /* CONFIG_FUNCTION_GRAPH_TRACER */
>> +
>> +#ifdef CONFIG_FTRACE_SELFTEST
>> +#ifdef CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS
>> +SYM_FUNC_START(trace_direct_tramp)
>> +	mov	x10, x30
>> +	mov	x30, x9
>> +	ret	x10
>> +SYM_FUNC_END(trace_direct_tramp)
>> +#endif /* CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS */
>> +#endif /* CONFIG_FTRACE_SELFTEST */
>> diff --git a/kernel/trace/trace_selftest.c b/kernel/trace/trace_selftest.c
>> index abcadbe933bb..38b0d5c9a1e0 100644
>> --- a/kernel/trace/trace_selftest.c
>> +++ b/kernel/trace/trace_selftest.c
>> @@ -785,7 +785,7 @@ static struct fgraph_ops fgraph_ops __initdata  = {
>>  };
>>  
>>  #ifdef CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS
>> -noinline __noclone static void trace_direct_tramp(void) { }
>> +void __weak trace_direct_tramp(void) { }
>>  #endif
>>  
>>  /*
> 
> 
>> @@ -868,6 +868,8 @@ trace_selftest_startup_function_graph(struct tracer *trace,
>>  	if (ret)
>>  		goto out;
>>  
>> +	DYN_FTRACE_TEST_NAME();
> 
> This doesn't look like it belongs in this patch.
> 
> -- Steve

This was added to run trace_direct_tramp() separately before registering
function graph, so the dead loop can be caught accurately. However, the
dead loop can also be caught when running function graph test, so this
is somewhat unnecessary and will be removed in v3.

> 
>> +
>>  	ret = register_ftrace_graph(&fgraph_ops);
>>  	if (ret) {
>>  		warn_failed_init_tracer(trace, ret);
> 
> .


WARNING: multiple messages have this Message-ID (diff)
From: Xu Kuohai <xukuohai@huawei.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: <bpf@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <netdev@vger.kernel.org>,
	<linux-kselftest@vger.kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	 Will Deacon <will@kernel.org>, Ingo Molnar <mingo@redhat.com>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Alexei Starovoitov <ast@kernel.org>,
	Zi Shen Lim <zlim.lnx@gmail.com>,
	Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
	Yonghong Song <yhs@fb.com>,
	John Fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@kernel.org>,
	"David S . Miller" <davem@davemloft.net>,
	Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
	David Ahern <dsahern@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>, <x86@kernel.org>,
	<hpa@zytor.com>, Shuah Khan <shuah@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Ard Biesheuvel <ardb@kernel.org>,
	Pasha Tatashin <pasha.tatashin@soleen.com>,
	Peter Collingbourne <pcc@google.com>,
	Daniel Kiss <daniel.kiss@arm.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Steven Price <steven.price@arm.com>,
	Marc Zyngier <maz@kernel.org>, Mark Brown <broonie@kernel.org>,
	Kumar Kartikeya Dwivedi <memxor@gmail.com>,
	Delyan Kratunov <delyank@fb.com>
Subject: Re: [PATCH bpf-next v2 2/6] ftrace: Fix deadloop caused by direct call in ftrace selftest
Date: Thu, 21 Apr 2022 11:01:49 +0800	[thread overview]
Message-ID: <0c8976f2-c2d9-8f32-3d2a-725c060fc7e9@huawei.com> (raw)
In-Reply-To: <20220420192405.4e43a966@gandalf.local.home>

On 4/21/2022 7:24 AM, Steven Rostedt wrote:
> On Thu, 14 Apr 2022 12:22:16 -0400
> Xu Kuohai <xukuohai@huawei.com> wrote:
> 
>> After direct call is enabled for arm64, ftrace selftest enters a
>> dead loop:
>>
>> <trace_selftest_dynamic_test_func>:
>> 00  bti     c
>> 01  mov     x9, x30                            <trace_direct_tramp>:
>> 02  bl      <trace_direct_tramp>    ---------->     ret
>>                                                      |
>>                                          lr/x30 is 03, return to 03
>>                                                      |
>> 03  mov     w0, #0x0   <-----------------------------|
>>      |                                               |
>>      |                   dead loop!                  |
>>      |                                               |
>> 04  ret   ---- lr/x30 is still 03, go back to 03 ----|
>>
>> The reason is that when the direct caller trace_direct_tramp() returns
>> to the patched function trace_selftest_dynamic_test_func(), lr is still
>> the address after the instrumented instruction in the patched function,
>> so when the patched function exits, it returns to itself!
>>
>> To fix this issue, we need to restore lr before trace_direct_tramp()
>> exits, so make trace_direct_tramp() a weak symbol and rewrite it for
>> arm64.
>>
>> To detect this issue directly, call DYN_FTRACE_TEST_NAME() before
>> register_ftrace_graph().
>>
>> Reported-by: Li Huafei <lihuafei1@huawei.com>
>> Signed-off-by: Xu Kuohai <xukuohai@huawei.com>
>> ---
>>  arch/arm64/kernel/entry-ftrace.S | 10 ++++++++++
>>  kernel/trace/trace_selftest.c    |  4 +++-
>>  2 files changed, 13 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/kernel/entry-ftrace.S b/arch/arm64/kernel/entry-ftrace.S
>> index dfe62c55e3a2..e58eb06ec9b2 100644
>> --- a/arch/arm64/kernel/entry-ftrace.S
>> +++ b/arch/arm64/kernel/entry-ftrace.S
>> @@ -357,3 +357,13 @@ SYM_CODE_START(return_to_handler)
>>  	ret
>>  SYM_CODE_END(return_to_handler)
>>  #endif /* CONFIG_FUNCTION_GRAPH_TRACER */
>> +
>> +#ifdef CONFIG_FTRACE_SELFTEST
>> +#ifdef CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS
>> +SYM_FUNC_START(trace_direct_tramp)
>> +	mov	x10, x30
>> +	mov	x30, x9
>> +	ret	x10
>> +SYM_FUNC_END(trace_direct_tramp)
>> +#endif /* CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS */
>> +#endif /* CONFIG_FTRACE_SELFTEST */
>> diff --git a/kernel/trace/trace_selftest.c b/kernel/trace/trace_selftest.c
>> index abcadbe933bb..38b0d5c9a1e0 100644
>> --- a/kernel/trace/trace_selftest.c
>> +++ b/kernel/trace/trace_selftest.c
>> @@ -785,7 +785,7 @@ static struct fgraph_ops fgraph_ops __initdata  = {
>>  };
>>  
>>  #ifdef CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS
>> -noinline __noclone static void trace_direct_tramp(void) { }
>> +void __weak trace_direct_tramp(void) { }
>>  #endif
>>  
>>  /*
> 
> 
>> @@ -868,6 +868,8 @@ trace_selftest_startup_function_graph(struct tracer *trace,
>>  	if (ret)
>>  		goto out;
>>  
>> +	DYN_FTRACE_TEST_NAME();
> 
> This doesn't look like it belongs in this patch.
> 
> -- Steve

This was added to run trace_direct_tramp() separately before registering
function graph, so the dead loop can be caught accurately. However, the
dead loop can also be caught when running function graph test, so this
is somewhat unnecessary and will be removed in v3.

> 
>> +
>>  	ret = register_ftrace_graph(&fgraph_ops);
>>  	if (ret) {
>>  		warn_failed_init_tracer(trace, ret);
> 
> .


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-04-21  3:02 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-14 16:22 [PATCH bpf-next v2 0/6] bpf trampoline for arm64 Xu Kuohai
2022-04-14 16:22 ` Xu Kuohai
2022-04-14 16:22 ` [PATCH bpf-next v2 1/6] arm64: ftrace: Add ftrace direct call support Xu Kuohai
2022-04-14 16:22   ` Xu Kuohai
2022-04-14 16:22 ` [PATCH bpf-next v2 2/6] ftrace: Fix deadloop caused by direct call in ftrace selftest Xu Kuohai
2022-04-14 16:22   ` Xu Kuohai
2022-04-20 23:24   ` Steven Rostedt
2022-04-20 23:24     ` Steven Rostedt
2022-04-21  3:01     ` Xu Kuohai [this message]
2022-04-21  3:01       ` Xu Kuohai
2022-04-14 16:22 ` [PATCH bpf-next v2 3/6] bpf: Move is_valid_bpf_tramp_flags() to the public trampoline code Xu Kuohai
2022-04-14 16:22   ` Xu Kuohai
2022-04-14 16:22 ` [PATCH bpf-next v2 4/6] bpf, arm64: Impelment bpf_arch_text_poke() for arm64 Xu Kuohai
2022-04-14 16:22   ` Xu Kuohai
2022-04-15  2:34   ` Hou Tao
2022-04-15  2:34     ` Hou Tao
2022-04-15  3:39     ` Xu Kuohai
2022-04-15  3:39       ` Xu Kuohai
2022-04-22 10:54   ` Jakub Sitnicki
2022-04-22 10:54     ` Jakub Sitnicki
2022-04-24  5:05     ` Xu Kuohai
2022-04-24  5:05       ` Xu Kuohai
2022-04-25 14:26       ` Jakub Sitnicki
2022-04-25 14:26         ` Jakub Sitnicki
2022-04-26  4:01         ` Xu Kuohai
2022-04-26  4:01           ` Xu Kuohai
2022-04-14 16:22 ` [PATCH bpf-next v2 5/6] bpf, arm64: bpf trampoline " Xu Kuohai
2022-04-14 16:22   ` Xu Kuohai
2022-04-15 17:12   ` Andrii Nakryiko
2022-04-15 17:12     ` Andrii Nakryiko
2022-04-16  1:57     ` Xu Kuohai
2022-04-16  1:57       ` Xu Kuohai
2022-04-20  7:43       ` Xu Kuohai
2022-04-20  7:43         ` Xu Kuohai
2022-04-20 11:42         ` KP Singh
2022-04-20 11:42           ` KP Singh
2022-04-14 16:22 ` [PATCH bpf-next v2 6/6] selftests/bpf: Fix trivial typo in fentry_fexit.c Xu Kuohai
2022-04-14 16:22   ` Xu Kuohai
2022-04-15  2:37 ` [PATCH bpf-next v2 0/6] bpf trampoline for arm64 Hou Tao
2022-04-15  2:37   ` Hou Tao
2022-04-15  3:47   ` Xu Kuohai
2022-04-15  3:47     ` Xu Kuohai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0c8976f2-c2d9-8f32-3d2a-725c060fc7e9@huawei.com \
    --to=xukuohai@huawei.com \
    --cc=andrii@kernel.org \
    --cc=ardb@kernel.org \
    --cc=ast@kernel.org \
    --cc=bp@alien8.de \
    --cc=bpf@vger.kernel.org \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=daniel.kiss@arm.com \
    --cc=daniel@iogearbox.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=davem@davemloft.net \
    --cc=delyank@fb.com \
    --cc=dsahern@kernel.org \
    --cc=hpa@zytor.com \
    --cc=john.fastabend@gmail.com \
    --cc=kafai@fb.com \
    --cc=kpsingh@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=memxor@gmail.com \
    --cc=mingo@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=pasha.tatashin@soleen.com \
    --cc=pcc@google.com \
    --cc=rostedt@goodmis.org \
    --cc=shuah@kernel.org \
    --cc=songliubraving@fb.com \
    --cc=steven.price@arm.com \
    --cc=sudeep.holla@arm.com \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    --cc=yhs@fb.com \
    --cc=yoshfuji@linux-ipv6.org \
    --cc=zlim.lnx@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.