On Mon, 10 Aug 2026 14:32:30 +0800
Michael Wu <[email protected]> wrote:
> The following sequence may leads race between event_define_fields()
> and update_event_fields():
> CPU0 (module A, pri=1 notifier) CPU1 (module B, pri=0 notifier)
What does the above mean? Are you loading two modules at the same time?
What does "pri=X notifier" mean? What function calls are these coming from?
-- Steve
> =============================== ===============================
> event_define_fields(call_A) trace_event_update_all()
> for each f: list_for_each_entry(...,
> list_add(&f->link, &ftrace_events)
> &class->fields) -> finds call_A
> f->link.next = next; (2)
> update_event_fields(call_A)
> WRITE_ONCE(class->fields->next,
> &f->link); (4)
> list_for_each_entry(field,
> &class->fields, link)
> -> field = class->fields->next
> = &f->link
> = f (offset 0)
> -> arm64 weak ordering:
> (4) visible before (2)
> field->link.next == 0
> -> next iteration:
> field = (void *)0 = NULL
> -> crash at NULL->type (0x18)
>
> This produces the following panic:
> Unable to handle kernel access ... at virtual address 0000000000000018
> pc : update_event_fields+0xf8/0x368
> Call trace:
> update_event_fields+0xf8/0x368
> trace_event_update_all+0x7c/0x2b4
> trace_module_notify+0x4c/0x1dc
> notifier_call_chain+0x84/0x168
> blocking_notifier_call_chain_robust+0x64/0xd4
> load_module+0x10c8/0x123c
> __arm64_sys_finit_module+0x230/0x31c
>
> Fix by taking event_mutex in trace_event_update_all() before
> trace_event_sem.
>
> Fixes: b3bc8547d3be ("tracing: Have TRACE_DEFINE_ENUM affect trace event
> types as well")
> Cc: [email protected]
> Signed-off-by: Michael Wu <[email protected]>
