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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ