From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
To: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Cc: Naresh Kamboju <naresh.kamboju@linaro.org>,
Steven Rostedt <rostedt@goodmis.org>,
open list <linux-kernel@vger.kernel.org>,
Linux trace kernel <linux-trace-kernel@vger.kernel.org>,
lkft-triage@lists.linaro.org,
Stephen Rothwell <sfr@canb.auug.org.au>,
Arnd Bergmann <arnd@arndb.de>,
Dan Carpenter <dan.carpenter@linaro.org>,
Anders Roxell <anders.roxell@linaro.org>
Subject: Re: next-20250605: Test regression: qemu-x86_64-compat mode ltp tracing Oops int3 kernel panic
Date: Mon, 16 Jun 2025 16:36:59 +0900 [thread overview]
Message-ID: <20250616163659.d372cf60ee0c476168cd448e@kernel.org> (raw)
In-Reply-To: <20250613172753.3479f786d40c29ec7b51df0a@kernel.org>
On Fri, 13 Jun 2025 17:27:53 +0900
Masami Hiramatsu (Google) <mhiramat@kernel.org> wrote:
> > Run 3:
> > - https://lkft.validation.linaro.org/scheduler/job/8311139#L1703
>
> This is the same as Run 2, and clearer.
>
> In do_int3(), if we hit a disappeared int3, it is evacuated after
> all. This means kprobe_int3_handler() is hit, and call get_kprobe()
> to find the corresponding kprobes. But,
>
> ffffffff8150a040 <get_kprobe>:
> ffffffff8150a040: f3 0f 1e fa endbr64
> ffffffff8150a044: e8 07 b0 e2 ff call ffffffff81335050 <__fentry__>
> ffffffff8150a049: 48 b8 eb 83 b5 80 46 movabs $0x61c8864680b583eb,%rax
> ffffffff8150a050: 86 c8 61
>
> It hits the ftrace and hooked by fgraph, and eventually returns
> via ftrace_return_to_handler()
>
> [ 137.338572] RIP: 0010:ftrace_return_to_handler+0xd5/0x1f0
> [ 137.338577] Code: 00 89 55 c8 48 85 ff 74 07 4c 89 b7 80 00 00 00 49 8b 94 24 38 0b 00 00 48 98 48 8b 04 c2 48 c1 e8 0c 0f b7 c0 48 89 45 b8 cc <90> 48 8b 05 e3 ac c2 01 48 63 80 f8 00 00 00 48 0f a3 45 b8 72 39
>
> This address is;
>
> $ eu-addr2line -fi -e vmlinux ftrace_return_to_handler+0xd5
> arch_static_branch inlined at /builds/linux/kernel/trace/fgraph.c:839:6 in ftrace_return_to_handler
> /builds/linux/arch/x86/include/asm/jump_label.h:36:2
> __ftrace_return_to_handler
> /builds/linux/kernel/trace/fgraph.c:839:6
> ftrace_return_to_handler
> /builds/linux/kernel/trace/fgraph.c:874:9
>
> It is for static_branch, which also uses a text_poke.
>
> -----
> #ifdef CONFIG_HAVE_STATIC_CALL
> if (static_branch_likely(&fgraph_do_direct)) { <======
> if (test_bit(fgraph_direct_gops->idx, &bitmap))
> static_call(fgraph_retfunc)(&trace, fgraph_direct_gops, fregs);
> -----
>
> But actually, this static_branch modifies the kernel code with
> smp_text_poke_single() (note, this is a wrapper of smp_text_poke_batch).
>
> And this is MISSED by the smp_text_poke_int3_handler() again and
> go through the kprobes, and hit ftrace (fgraph) and caused this
> loop.
>
> So the fundamental issue is that smp_text_poke_batch missed
> handling INT3.
>
> I guess some text_poke user do not get text_mutex?
Hmm, I've checked the smp_text_poke_* users, but it seems no problem.
Basically, those smp_text_poke* user locks text_mutex, and another
suspicious ftrace_start_up is also set under ftrace_lock.
ftrace_arch_code_modify_post_process() is also paired with
ftrace_arch_code_modify_prepare() and under ftrace_lock.
smp_text_poke_single()
ftrace_mod_jmp()
ftrace_enable_ftrace_graph_caller()
ftrace_modify_all_code() -> see [*1]
ftrace_disable_ftrace_graph_caller()
ftrace_modify_all_code() -> see [*1]
ftrace_update_ftrace_func()
update_ftrace_func()
ftrace_modify_all_code() -> see [*1]
smp_text_poke_batch_add()
arch_jump_label_transform_queue() -> lock text_mutex
ftrace_replace_code()
ftrace_modify_all_code() <------[*1]
arch_ftrace_update_code()
ftrace_run_update_code() -> lock text_mutex
ftrace_modify_code_direct() (only if ftrace_poke_late != 0)
ftrace_make_nop()
__ftrace_replace_code() <----[*3]
ftrace_replace_code(weak) --> Not used on x86 (overridden)
ftrace_modify_all_code() <--- [*1]
arch_ftrace_update_code() <---- [*4]
ftrace_run_update_code()-> lock text_mutex
__ftrace_modify_code()
ftrace_run_stop_machine()
arch_ftrace_update_code(weak) -> overridden on x86 see [*4]
ftrace_module_enable() -> lock text_mutex (see below)
ftrace_init_nop()
ftrace_nop_initialize()
ftrace_update_code()
ftrace_module_enable() -> lock text_mutex
prepare_coming_module()
load_modole()
ftrace_process_locs() -> lock ftrace_lock.
ftrace_init() -> OK (ftrace_poke_late == 0 because its early)
ftrace_module_init() -> OK (ftrace_poke_late == 0 because module is not live)
load_module()
ftrace_make_call()
__ftrace_replace_code() -> see [*3]
smp_text_poke_batch_finish()
arch_jump_label_transform_apply() -> lock text_mutex
ftrace_arch_code_modify_post_process() -> must be OK because this unlock text_mutex
ftrace_run_update_code()-> paired with ftrace_arch_code_modify_prepare()
ftrace_module_enable()-> paired with ftrace_arch_code_modify_prepare() (depends on ftrace_lock && ftrace_start_up)
ftrace_replace_code()
ftrace_modify_all_code() -> see [*1]
ftrace_start_up <does variable set under ftrace_lock ?>
ftrace_startup()
ftrace_startup_subops()
register_ftrace_graph() -> lock ftrace_lock
register_ftrace_function_probe() -> lock ftrace_lock
register_ftrace_function_nolock() -> lock ftrace_lock
ftrace_shutdown()
unregister_ftrace_function() -> lock ftrace_lock
ftrace_arch_code_modify_prepare() < this set ftrace_poke_late = 1>
ftrace_module_enable() -> lock ftrace_lock.
ftrace_run_update_code()
ftrace_run_modify_code()
ftrace_ops_update_code()
__ftrace_hash_move_and_update_ops()
ftrace_update_ops()
ftrace_startup_subops()
register_ftrace_graph() -> lock ftrace_lock
ftrace_shutdown_subops()
unregister_ftrace_graph() -> lock ftrace_lock
ftrace_hash_move_and_update_subops()
ftrace_hash_move_and_update_ops() -> [*2]
ftrace_hash_move_and_update_ops() <-- [*2]
process_mod_list() -> lock ftrace_lock
register_ftrace_function_probe() -> lock ftrace_lock
unregister_ftrace_function_probe_func() -> lock ftrace_lock
ftrace_set_hash() -> lock ftrace_lock
ftrace_regex_release() -> lock ftrace_lock
unregister_ftrace_function_probe_func() -> lock ftrace_lock
ftrace_startup_enable()
ftrace_startup_all()
ftrace_pid_reset() -> lock ftrace_lock
pid_write() -> lock ftrace_lock
ftrace_startup()
ftrace_startup_subops()
register_ftrace_graph() -> lock ftrace_lock
register_ftrace_function_probe() -> lock ftrace_lock
register_ftrace_function_nolock() -> lock ftrace_lock
ftrace_startup_sysctl()
ftrace_enable_sysctl() -> lock ftrace_lock
ftrace_shutdown()
ftrace_shutdown_subops()
unregister_ftrace_graph() -> lock ftrace_lock
unregister_ftrace_function_probe_func() -> lock ftrace_lock
ftrace_destroy_filter_files() -> lock ftrace_lock
unregister_ftrace_function() -> lock ftrace_lock
ftrace_shutdown_sysctl()
ftrace_enable_sysctl() -> lock ftrace_lock
Thanks,
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
next prev parent reply other threads:[~2025-06-16 7:37 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-05 11:42 next-20250605: Test regression: qemu-x86_64-compat mode ltp tracing Oops int3 kernel panic Naresh Kamboju
2025-06-09 13:09 ` Masami Hiramatsu
2025-06-10 8:41 ` Masami Hiramatsu
2025-06-10 13:25 ` Steven Rostedt
2025-06-10 13:20 ` Naresh Kamboju
2025-06-10 14:43 ` Masami Hiramatsu
2025-06-10 14:47 ` [RFC PATCH 1/2] x86: Retry with new instruction if INT3 is disappaered Masami Hiramatsu (Google)
2025-06-10 14:47 ` [RFC PATCH 2/2] x86: alternative: Invalidate the cache for updated instructions Masami Hiramatsu (Google)
2025-06-10 15:50 ` Steven Rostedt
2025-06-11 0:21 ` Masami Hiramatsu
2025-06-11 10:26 ` Masami Hiramatsu
2025-06-11 14:20 ` Steven Rostedt
2025-06-11 15:42 ` Steven Rostedt
2025-06-12 0:04 ` Masami Hiramatsu
2025-06-11 11:30 ` Peter Zijlstra
2025-06-12 0:17 ` Masami Hiramatsu
2025-06-12 16:24 ` Naresh Kamboju
2025-06-13 3:09 ` Masami Hiramatsu
2025-06-10 14:53 ` next-20250605: Test regression: qemu-x86_64-compat mode ltp tracing Oops int3 kernel panic Steven Rostedt
2025-06-12 13:09 ` Naresh Kamboju
2025-06-13 8:27 ` Masami Hiramatsu
2025-06-13 12:01 ` Masami Hiramatsu
2025-06-16 7:36 ` Masami Hiramatsu [this message]
2025-06-17 10:41 ` Masami Hiramatsu
2025-06-17 12:10 ` Naresh Kamboju
2025-06-17 12:25 ` Steven Rostedt
2025-06-17 12:31 ` Naresh Kamboju
2025-06-17 14:29 ` Steven Rostedt
2025-06-17 23:40 ` Masami Hiramatsu
2025-06-19 14:00 ` Steven Rostedt
2025-06-17 16:45 ` Naresh Kamboju
2025-06-17 23:05 ` Masami Hiramatsu
2025-06-17 23:32 ` Steven Rostedt
2025-06-10 0:29 ` Steven Rostedt
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=20250616163659.d372cf60ee0c476168cd448e@kernel.org \
--to=mhiramat@kernel.org \
--cc=anders.roxell@linaro.org \
--cc=arnd@arndb.de \
--cc=dan.carpenter@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=lkft-triage@lists.linaro.org \
--cc=naresh.kamboju@linaro.org \
--cc=rostedt@goodmis.org \
--cc=sfr@canb.auug.org.au \
/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.