| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <20251028105549.ae94e8eeb42f4efc183d2807@kernel.org>
Date: Tue, 28 Oct 2025 10:55:49 +0900
From: Masami Hiramatsu (Google) <mhiramat@...nel.org>
To: Masami Hiramatsu (Google) <mhiramat@...nel.org>, Catalin Marinas
<catalin.marinas@....com>, Will Deacon <will@...nel.org>
Cc: Mark Brown <broonie@...nel.org>, Steven Rostedt <rostedt@...dmis.org>,
Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...nel.org>,
x86@...nel.org, Jinchao Wang <wangjinchao600@...il.com>, Mathieu Desnoyers
<mathieu.desnoyers@...icios.com>, Thomas Gleixner <tglx@...utronix.de>,
Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>,
"H . Peter Anvin" <hpa@...or.com>, Alexander Shishkin
<alexander.shishkin@...ux.intel.com>, Ian Rogers <irogers@...gle.com>,
linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
linux-doc@...r.kernel.org, linux-perf-users@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, Aishwarya.TCV@....com
Subject: Re: [PATCH v5 6/8] selftests: tracing: Add a basic testcase for
wprobe
On Tue, 28 Oct 2025 08:42:22 +0900
Masami Hiramatsu (Google) <mhiramat@...nel.org> wrote:
> ~ # cd /sys/kernel/tracing/
> /sys/kernel/tracing # echo 'w:my_wprobe w@...fies' >> dynamic_events
> /sys/kernel/tracing # echo 1 > events/wprobes/my_wprobe/enable
> [ 54.942288] trace_wprobe: enable_trace_wprobe called
> [ 54.945306] trace_wprobe: trying to register wprobes
> [ 54.947367] trace_wprobe: __register_trace_wprobe called
> [ 54.949586] trace_wprobe: registering wprobe at addr: 0xffffb6ce429fb200, len: 4, type: 2
> [ 54.951639] Creating wide hw breakpoint on CPU 0
> [ 54.966390] Creating kernel counter on CPU 0 for event type 5
> [ 54.967758] perf_install_in_context: event 00000000736da1d9 ctx 000000005d4db900 cpu 0
> [ 54.972015] perf_install_in_context2: event 00000000736da1d9 ctx set to 000000005d4db900
> [ 54.976697] cpu_function_call: calling function on CPU 0, func: __perf_install_in_context+0x0/0x2c8
>
> What happen if the cpu calls function on itself by
> smp_call_function_single() on arm64?
>
> smp_call_function_single(this_cpu, remote_function, &data, 1);
Sorry, that was printk buffering issue. I used trace_printk() instead
and persistent ring buffer[1] to trace it.
[1] https://docs.kernel.org/trace/debugging.html#persistent-buffers-across-boots
~ # echo 1 > /sys/kernel/tracing/instances/boot_map/options/trace_printk_dest
~ # echo 'w:my_wprobe w@...fies' >> /sys/kernel/tracing/dynamic_events
~ # echo 1 > /sys/kernel/tracing/events/wprobes/my_wprobe/enable
QEMU 8.2.2 monitor - type 'help' for more information
(qemu) system_reset
...
~ # cat /sys/kernel/tracing/instances/boot_map/trace
# tracer: nop
#
# entries-in-buffer/entries-written: 16/16 #P:1
#
# _-----=> irqs-off/BH-disabled
# / _----=> need-resched
# | / _---=> hardirq/softirq
# || / _--=> preempt-depth
# ||| / _-=> migrate-disable
# |||| / delay
# TASK-PID CPU# ||||| TIMESTAMP FUNCTION
# | | | ||||| | |
<...>-63 [000] ..... 21.065038: register_wide_hw_breakpoint: Creating wide hw breakpoint on CPU 0
<...>-63 [000] ..... 21.079678: perf_event_create_kernel_counter: Creating kernel counter on CPU 0 for event type 5
<...>-63 [000] ..... 21.080051: perf_install_in_context: perf_install_in_context: event 000000000b3ac4d3 ctx 00000000097d6337 cpu 0
<...>-63 [000] ..... 21.080140: perf_install_in_context: perf_install_in_context2: event 000000000b3ac4d3 ctx set to 00000000097d6337
<...>-63 [000] ..... 21.080939: cpu_function_call: cpu_function_call: calling function on CPU 0, func: __perf_install_in_context+0x0/0x2f0
<...>-63 [000] ..... 21.080966: smp_call_function_single: smp_call_function_single: calling function on CPU 0, func: remote_function+0x0/0x78, wait=1
<...>-63 [000] ...1. 21.080973: smp_call_function_single: smp_call_function_single: running on CPU 0, call CPU 0
<...>-63 [000] ...1. 21.081099: smp_call_function_single: smp_call_function_single: checking for potential deadlock conditions
<...>-63 [000] ...1. 21.081259: generic_exec_single: generic_exec_single: preparing to call function on CPU 0, func: remote_function+0x0/0x78
<...>-63 [000] ...1. 21.081269: generic_exec_single: Executing smp_call_function_single on self CPU 0, func: remote_function+0x0/0x78
<...>-63 [000] d..1. 21.081289: csd_do_func: csd_do_func: CPU 0 executing func remote_function+0x0/0x78
<...>-63 [000] d..1. 21.081429: __perf_install_in_context: __perf_install_in_context: event 000000000b3ac4d3 ctx 00000000097d6337
<...>-63 [000] d..2. 21.083211: hw_breakpoint_control: hw_breakpoint_control: ops=0
<...>-63 [000] d..1. 21.084191: __perf_install_in_context: __perf_install_in_context: event 000000000b3ac4d3 done, ret=0
<...>-63 [000] d..1. 21.084237: csd_do_func: csd_do_func: CPU 0 finished func remote_function+0x0/0x78
<...>-63 [000] d..1. 21.084243: generic_exec_single: Finished csd_lock_record(NULL)
~ #
So the last message is right before the local_irq_restore() in
generic_exec_single().
static int generic_exec_single(int cpu, call_single_data_t *csd)
{
...
csd_lock_record(csd);
csd_unlock(csd);
local_irq_save(flags);
csd_do_func(func, info, NULL);
csd_lock_record(NULL);
trace_printk("Finished csd_lock_record(NULL)\n"); <-
local_irq_restore(flags);
return 0;
Actually, I added another trace_printk() right after generic_exec_single().
err = generic_exec_single(cpu, csd);
trace_printk("generic_exec_single returned %d for CPU %d, func: %pS\n",
err, cpu, func);
This means after setting the hw_breakpoint, when enabing the IRQ,
the machine is frozen - but qemu is running busy.
Can we specify the kernel memory address to HW breakpoint on arm64?
Thank you,
--
Masami Hiramatsu (Google) <mhiramat@...nel.org>
Powered by blists - more mailing lists