[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20251028084222.a3c1ae97d125d9bd88fc565b@kernel.org>
Date: Tue, 28 Oct 2025 08:42:22 +0900
From: Masami Hiramatsu (Google) <mhiramat@...nel.org>
To: Masami Hiramatsu (Google) <mhiramat@...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 Mon, 27 Oct 2025 22:43:47 +0900
Masami Hiramatsu (Google) <mhiramat@...nel.org> wrote:
> On Fri, 24 Oct 2025 22:31:06 +0100
> Mark Brown <broonie@...nel.org> wrote:
>
> > On Tue, Sep 23, 2025 at 10:17:47AM +0900, Masami Hiramatsu (Google) wrote:
> > > From: Masami Hiramatsu (Google) <mhiramat@...nel.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@...fies'
> + 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@...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);
Thank you,
--
Masami Hiramatsu (Google) <mhiramat@...nel.org>
Powered by blists - more mailing lists