On 7/17/2026 9:41 AM, 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.
Thanks, Dave. I agree that adding another standalone in-kernel debugging facility of this size is not the right direction. The motivation was practical. I have encountered several silent memory corruption bugs for which I wrote similar one-off instrumentation to identify the writer. KWatch was an attempt to make that technique reusable instead of rebuilding it for each bug, and to reduce the same setup cost for other developers facing similar problems. This approach proved useful for localizing the dummy_hcd corruption: https://lore.kernel.org/all/[email protected]/ It identified the copy that overwrote req->complete and recorded the writer's call stack. So I believe the debugging use case is valid, but it does not require a separate KWatch implementation. As discussed in my reply to Masami and Boris, I will stop pursuing the standalone KWatch series and work with Masami on implementing the necessary scoped watchpoint features in wprobe/tracing instead. Thanks, Jinchao
