On 2025/12/3 0:43, Steven Rostedt wrote:
On Fri, 28 Nov 2025 10:27:42 +0800
yebin <[email protected]> wrote:

right before this BUG, don't you?
If you reported with that line, it's more easier to understand.

Yes, there is indeed a warning generated. I might not have expressed it
clearly enough. The issue below is related to the problem that occurs
when the second module is unloaded. When the first module was unloaded,
some nodes were left in the hash list, causing a use-after-free (UAF)
issue when traversing the hash list.
Therefore, this patch aims to resolve the UAF problem caused by residual
nodes in the hash list after unloading a module while ftrace is disabled.

ftrace_disabled is equivalent to BUG(). But it doesn't crash the system
immediately, but requires a reboot ASAP.

I'm not interested in fixing residual bugs that happen because of a
ftrace_disabled was triggered. The ftrace_disabled triggering is the cause
of this. It should *never* happen. If it does, it needs to be fixed.

Let's focus our attention on fixing the cause of ftrace_disabled. Anything
else is just waste of effort.

Do you have the output of the first warning when ftrace_disabled was
triggered?

The reason for ftrace_disable is a conflict between a livepatch and a module. This issue must be resolved. However, since this problem occurs in the current network environment, it does not affect the normal operation of services, so customers may not necessarily be willing to restart their systems to fix it. The only thing that can be done is to implement proper exception protection to ensure the system can continue to function until the customer is willing to upgrade and restart.

WARNING: CPU: 0 PID: 2394 at kernel/trace/ftrace.c:2603 ftrace_modify_all_code+0x81/0x140
 CPU: 0 PID: 2394 Comm: insmod Tainted: P           OE K
 RIP: 0010:ftrace_modify_all_code+0x81/0x140
 Call Trace:
  arch_ftrace_update_code+0xc/0x20
  ftrace_run_update_code+0x13/0x70
  ftrace_startup+0xc0/0x190
  register_ftrace_function+0x44/0x60
  arm_kprobe+0xc7/0x120
  register_kprobe+0x5f0/0x6a0
  kxxx_emerge_init+0x89/0xe0 [kxxx]
  kxxx_region_init+0x16d/0x330 [kxxx]
  kxxx_init+0xe3/0x1000 [kxxx]
  do_one_initcall+0x46/0x1c8
  do_init_module+0x5b/0x1fb
  load_module+0x15a7/0x1e20
  __do_sys_finit_module+0xe9/0x110
  do_syscall_64+0x5b/0x1b0
  entry_SYSCALL_64_after_hwframe+0x65/0xca

-- Steve



Reply via email to