From: Andrew Morton <akpm@linux-foundation.org>
To: Jinchao Wang <wangjinchao600@gmail.com>
Cc: Masami Hiramatsu <mhiramat@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Mike Rapoport <rppt@kernel.org>,
Alexander Potapenko <glider@google.com>,
Randy Dunlap <rdunlap@infradead.org>,
Marco Elver <elver@google.com>, Jonathan Corbet <corbet@lwn.net>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Valentin Schneider <vschneid@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>,
"Liang, Kan" <kan.liang@linux.intel.com>,
David Hildenbrand <david@redhat.com>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Vlastimil Babka <vbabka@suse.cz>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
Nathan Chancellor <nathan@kernel.org>,
Nick Desaulniers <nick.desaulniers+lkml@gmail.com>,
Bill Wendling <morbo@google.com>,
Justin Stitt <justinstitt@google.com>,
Kees Cook <kees@kernel.org>, Alice Ryhl <aliceryhl@google.com>,
Sami Tolvanen <samitolvanen@google.com>,
Miguel Ojeda <ojeda@kernel.org>,
Masahiro Yamada <masahiroy@kernel.org>, Rong Xu <xur@google.com>,
Naveen N Rao <naveen@kernel.org>,
David Kaplan <david.kaplan@amd.com>,
Andrii Nakryiko <andrii@kernel.org>,
Jinjie Ruan <ruanjinjie@huawei.com>,
Nam Cao <namcao@linutronix.de>,
workflows@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
linux-mm@kvack.org, llvm@lists.linux.dev,
Andrey Ryabinin <ryabinin.a.a@gmail.com>,
Andrey Konovalov <andreyknvl@gmail.com>,
Dmitry Vyukov <dvyukov@google.com>,
Vincenzo Frascino <vincenzo.frascino@arm.com>,
kasan-dev@googlegroups.com,
"David S. Miller" <davem@davemloft.net>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH v7 00/23] mm/ksw: Introduce real-time KStackWatch debugging tool
Date: Thu, 9 Oct 2025 17:51:07 -0700 [thread overview]
Message-ID: <20251009175107.ee07228e3253afca5b487316@linux-foundation.org> (raw)
In-Reply-To: <20251009105650.168917-1-wangjinchao600@gmail.com>
On Thu, 9 Oct 2025 18:55:36 +0800 Jinchao Wang <wangjinchao600@gmail.com> wrote:
> This patch series introduces KStackWatch, a lightweight debugging tool to detect
> kernel stack corruption in real time. It installs a hardware breakpoint
> (watchpoint) at a function's specified offset using `kprobe.post_handler` and
> removes it in `fprobe.exit_handler`. This covers the full execution window and
> reports corruption immediately with time, location, and a call stack.
>
> The motivation comes from scenarios where corruption occurs silently in one
> function but manifests later in another, without a direct call trace linking
> the two. Such bugs are often extremely hard to debug with existing tools.
> These scenarios are demonstrated in test 3–5 (silent corruption test, patch 20).
>
> ...
>
> 20 files changed, 1809 insertions(+), 62 deletions(-)
It's obviously a substantial project. We need to decide whether to add
this to Linux.
There are some really important [0/N] changelog details which I'm not
immediately seeing:
Am I correct in thinking that it's x86-only? If so, what's involved in
enabling other architectures? Is there any such work in progress?
What motivated the work? Was there some particular class of failures
which you were persistently seeing and wished to fix more efficiently?
Has this code (or something like it) been used in production systems?
If so, by whom and with what results?
Has it actually found some kernel bugs yet? If so, details please.
Can this be enabled on production systems? If so, what is the
measured runtime overhead?
next prev parent reply other threads:[~2025-10-10 0:51 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-09 10:55 Jinchao Wang
2025-10-09 10:55 ` [PATCH v7 01/23] x86/hw_breakpoint: Unify breakpoint install/uninstall Jinchao Wang
2025-10-09 10:55 ` [PATCH v7 02/23] x86/hw_breakpoint: Add arch_reinstall_hw_breakpoint Jinchao Wang
2025-10-09 10:55 ` [PATCH v7 03/23] HWBP: Add modify_wide_hw_breakpoint_local() API Jinchao Wang
2025-10-09 10:55 ` [PATCH v7 04/23] mm/ksw: add build system support Jinchao Wang
2025-10-09 10:55 ` [PATCH v7 05/23] mm/ksw: add ksw_config struct and parser Jinchao Wang
2025-10-09 10:55 ` [PATCH v7 06/23] mm/ksw: add singleton debugfs interface Jinchao Wang
2025-10-09 10:55 ` [PATCH v7 07/23] mm/ksw: add HWBP pre-allocation Jinchao Wang
2025-10-09 10:55 ` [PATCH v7 08/23] mm/ksw: Add atomic watchpoint management api Jinchao Wang
2025-10-09 10:55 ` [PATCH v7 09/23] mm/ksw: ignore false positives from exit trampolines Jinchao Wang
2025-10-09 10:55 ` [PATCH v7 10/23] mm/ksw: support CPU hotplug Jinchao Wang
2025-10-09 10:55 ` [PATCH v7 11/23] sched: add per-task context Jinchao Wang
2025-10-09 10:55 ` [PATCH v7 12/23] mm/ksw: add entry kprobe and exit fprobe management Jinchao Wang
2025-10-09 10:55 ` [PATCH v7 13/23] mm/ksw: add per-task ctx tracking Jinchao Wang
2025-10-09 10:55 ` [PATCH v7 14/23] mm/ksw: resolve stack watch addr and len Jinchao Wang
2025-10-09 10:55 ` [PATCH v7 15/23] mm/ksw: manage probe and HWBP lifecycle via procfs Jinchao Wang
2025-10-09 10:55 ` [PATCH v7 16/23] mm/ksw: add self-debug helpers Jinchao Wang
2025-10-09 10:55 ` [PATCH v7 17/23] mm/ksw: add test module Jinchao Wang
2025-10-09 10:55 ` [PATCH v7 18/23] mm/ksw: add stack overflow test Jinchao Wang
2025-10-09 10:55 ` [PATCH v7 19/23] mm/ksw: add recursive depth test Jinchao Wang
2025-10-09 10:55 ` [PATCH v7 20/23] mm/ksw: add multi-thread corruption test cases Jinchao Wang
2025-10-09 10:55 ` [PATCH v7 21/23] tools/ksw: add test script Jinchao Wang
2025-10-09 10:55 ` [PATCH v7 22/23] docs: add KStackWatch document Jinchao Wang
2025-10-10 20:02 ` Randy Dunlap
2025-10-09 10:55 ` [PATCH v7 23/23] MAINTAINERS: add entry for KStackWatch Jinchao Wang
2025-10-10 0:51 ` Andrew Morton [this message]
2025-10-10 7:58 ` [PATCH v7 00/23] mm/ksw: Introduce real-time KStackWatch debugging tool Jinchao Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251009175107.ee07228e3253afca5b487316@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=Liam.Howlett@oracle.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=aliceryhl@google.com \
--cc=andreyknvl@gmail.com \
--cc=andrii@kernel.org \
--cc=bp@alien8.de \
--cc=bsegall@google.com \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=david.kaplan@amd.com \
--cc=david@redhat.com \
--cc=dietmar.eggemann@arm.com \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=glider@google.com \
--cc=hpa@zytor.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=juri.lelli@redhat.com \
--cc=justinstitt@google.com \
--cc=kan.liang@linux.intel.com \
--cc=kasan-dev@googlegroups.com \
--cc=kees@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=lorenzo.stoakes@oracle.com \
--cc=mark.rutland@arm.com \
--cc=masahiroy@kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mgorman@suse.de \
--cc=mhiramat@kernel.org \
--cc=mhocko@suse.com \
--cc=mingo@redhat.com \
--cc=morbo@google.com \
--cc=namcao@linutronix.de \
--cc=namhyung@kernel.org \
--cc=nathan@kernel.org \
--cc=naveen@kernel.org \
--cc=nick.desaulniers+lkml@gmail.com \
--cc=ojeda@kernel.org \
--cc=peterz@infradead.org \
--cc=rdunlap@infradead.org \
--cc=rostedt@goodmis.org \
--cc=rppt@kernel.org \
--cc=ruanjinjie@huawei.com \
--cc=ryabinin.a.a@gmail.com \
--cc=samitolvanen@google.com \
--cc=surenb@google.com \
--cc=tglx@linutronix.de \
--cc=vbabka@suse.cz \
--cc=vincent.guittot@linaro.org \
--cc=vincenzo.frascino@arm.com \
--cc=vschneid@redhat.com \
--cc=wangjinchao600@gmail.com \
--cc=workflows@vger.kernel.org \
--cc=x86@kernel.org \
--cc=xur@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox