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 [off-list ref] wrote:

On Fri, Jul 17, 2026 at 06:41:49AM -0700, Dave Hansen wrote:

quoted

On 7/17/26 05:50, Jinchao Wang wrote:

quoted

 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/ (local)

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) [off-list ref]