Re: [PATCH v12 04/11] tracing/wprobe: Add wprobe (watchpoint probe) trace event support

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

On Fri, 07 Aug 2026 15:59:14 +0000
sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] Hardware breakpoints are not synchronized with module unloads, leading to dangling breakpoints on reallocated memory.
> --
> 
> --- Patch [4]: [PATCH v12 04/11] tracing/wprobe: Add wprobe (watchpoint probe) trace event support ---
> commit 6f99af1ed7b9527ff7af700fbd99ed2a3d0632d9
> Author: Masami Hiramatsu (Google) <mhiramat@kernel.org>
> 
> tracing/wprobe: Add wprobe (watchpoint probe) trace event support
> 
> This commit adds wprobe, a hardware-breakpoint-based dynamic trace event.
> It allows users to monitor memory accesses by setting hardware breakpoints
> on specified addresses or symbols and logging the access context.
> 
> Link: https://lore.kernel.org/all/59637b96946653393a7ad3c7de094094796b39c2.1785067572.git.wangjinchao600@gmail.com/
> 
> > diff --git a/kernel/trace/trace_wprobe.c b/kernel/trace/trace_wprobe.c
> > new file mode 100644
> > index 0000000000000..df592d9280a47
> > --- /dev/null
> > +++ b/kernel/trace/trace_wprobe.c
> [ ... ]
> > +static int __register_trace_wprobe(struct trace_wprobe *tw)
> > +{
> > +	struct perf_event_attr attr;
> > +	int i, ret;
> [ ... ]
> > +	hw_breakpoint_init(&attr);
> > +	attr.bp_addr = tw->addr;
> > +	attr.bp_len = tw->len;
> > +	attr.bp_type = tw->type;
> > +
> > +	tw->bp_event = register_wide_hw_breakpoint(&attr, wprobe_perf_handler, tw);
>         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> [Severity: Medium]
> When a watchpoint probe is created for a module symbol, does this leave a
> dangling hardware breakpoint if the module is later unloaded?
> 
> Since the wprobe subsystem doesn't seem to register a module notifier
> (unlike kprobes) to clean up when modules are unloaded, the breakpoint stays
> active on the raw virtual address. If that memory is freed and subsequently
> reallocated for a different module or vmalloc allocation, could this lead
> to spurious trace events and unintended performance overhead on the reused
> memory?

Yeah, but this wprobe is for debugging feature, so it will be used for
tracking UAF too. Thus I would like to keep this as it is now.
We can add module symbol support (e.g. :mod:sym instead of sym) but that
should be done as a different improvement.

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