Re: [PATCH v5 6/8] selftests: tracing: Add a basic testcase for wprobe

[Masami Hiramatsu (Google) <mhiramat@kernel.org>]

On Mon, 27 Oct 2025 22:43:47 +0900
Masami Hiramatsu (Google) <mhiramat@kernel.org> wrote:

> On Fri, 24 Oct 2025 22:31:06 +0100
> Mark Brown <broonie@kernel.org> wrote:
> 
> > On Tue, Sep 23, 2025 at 10:17:47AM +0900, Masami Hiramatsu (Google) wrote:
> > > From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
> > > 
> > > Add 'add_remove_wprobe.tc' testcase for testing wprobe event that
> > > tests adding and removing operations of the wprobe event.
> > 
> > Since this series has landed in -next we've been seeing hangs on a range
> > of arm64 platforms running the ftrace tests, it looks like it's all of
> > them.  Unfortunately the systems lock up with no output as soon as they
> > start trying to do something with wprobes:
> > 
> > # ok 19 Generic dynamic event - add/remove kprobe events
> > # ok 20 Generic dynamic event - add/remove synthetic events
> > # ok 21 Generic dynamic event - add/remove tracepoint probe events
> > # ok 22 Generic dynamic event - add/remove tracepoint probe events on module
> > # ok 23 Generic dynamic event - add/remove/test uprobe events
> > 
> > the next test being add_remove_wprobe.tc, which doesn't seem to
> > complete.  Full log (for what little it's worth):
> > 
> >    https://lava.sirena.org.uk/scheduler/job/2000440#L1860
> > 
> > I turned on -vvv logging and that generated the rather spectacularly
> > more verbose:
> > 
> >    https://lava.sirena.org.uk/scheduler/job/2000676/log_file/plain
> > 
> > (in a somewhat processed format unfortunately.).  Looking at that log I
> > do notice a bunch of "unexpected operators" reported by the shell, these
> > systems are running dash not bash, though that doesn't seem related.  It
> > looks like the script hangs in reset_trigger_file while grepping the
> > trigger files rather than actually trying to do the test.
> > 
> > Sorry about the delay in reporting this.
> 
> OK, eventually, I confirmed it is stopped on enabling wprobe
> 
> + . /mnt/ftrace/test.d/dynevent/add_remove_wprobe.tc
> + echo 0
> + echo
> + TARGET=jiffies
> + echo 'w:my_wprobe w@jiffies'
> + grep -q my_wprobe dynamic_events
> + '[' 0 -ne 0 ]
> + test -d events/wprobes/my_wprobe
> + '[' 0 -ne 0 ]
> + echo 1
> 

Interestingly, this stops in the cpu_function_call(). It does not call
__perf_install_in_context().

~ # cd /sys/kernel/tracing/
/sys/kernel/tracing # echo 'w:my_wprobe w@jiffies' >> 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);

Thank you,

-- 
Masami Hiramatsu (Google) <mhiramat@kernel.org>