Re: [RFC PATCH v2 00/13] mm/kwatch: dynamic hardware watchpoints for hunting memory corruption

On Fri, 17 Jul 2026 11:10:04 -0700
Borislav Petkov <[email protected]> wrote:

> On Fri, Jul 17, 2026 at 06:41:49AM -0700, Dave Hansen wrote:
> > On 7/17/26 05:50, Jinchao Wang wrote:
> > >  24 files changed, 2115 insertions(+), 63 deletions(-)
> > Reading this, I wonder how many kernel debugging features we need. I
> > don't even think we have a centralized list of them. They all just live
> > in their own silos.
> > 
> > This one really seems like a super specialized tool. It has to be
> > enabled at compile time and specifically aimed at a specific function.
> > 
> > Maybe this should live off on the side for a while. If folks end up
> > actually needing it, they can point their friendly LLM over to its tree.
> 
> Right, and in my mbox right under this mail thread there's a
> 
> https://lore.kernel.org/all/178429796992.157981.3393977217853767915.stgit@devnote2/
> 
> which Masami has been blasting almost every day this week which contains two
> of the patches from this set here...

Sorry about that. I tried to fix the reviewed comment from Sashiko,
but I should wait for someone's comment.

> 
> Looks to me like folks need to sit down and agree on strategy first.

Yeah, I need to talk with Jinchao.

Like kprobe, wprobe itself integrates watchpoint functionality into
the tracing subsystem. Jinchao, I would like to ask you to redesign
the kwatch tool based on fprobe and wprobe events in user space?
I think that could reduce redundant efforts on the similar feature.

Using fprobe entry and exit event trigger, we can make a Function-
scoped watch window. Also, since fprobe and wprobe are having BTF
typecast support, you can access to the members of data structures
more naturally.

If you are interested, I would be open to having you handle the
development of the necessary features for wprobe.

Thank you,

-- 
Masami Hiramatsu (Google) <[email protected]>