From nobody Thu Oct 2 02:13:22 2025 Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D10E326FDBB for ; Tue, 30 Sep 2025 02:46:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.174 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759200369; cv=none; b=CocIQUCuQV6pvp4D4JuVQzoGJW903aeemnqToNqGGsTtzJczEwDbMyQcfWcn42DANQfO+IZff/bv7chFJGXOAjaJJ8nwxu0weX88BfIX/xUZkoYxYIGdtujh8/d417D8lVJ3IUd0mKNerSrLjq2nIRnojeEJPGahESbPokRT8kY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759200369; c=relaxed/simple; bh=fqSTZakucv5x/6mevb99A5bIyJAUPszvDZjEXujGW3E=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=oV0g6tesi1oPeRJkiLG6BMuIzGHJl56M8XZ+LqRiE2f/nJJkw5btqdlNEfI4e9Zczxdsn9hM1oqlJGxrDhkRsAYRKNeRLMkO/5k5gbAveWQuPx24oD/cfd1IuLQpkPjqftMrMOWxGrXPzrBjZopMlXPjoWlmOYzh7ynYY3wRM0U= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=hwGkXK96; arc=none smtp.client-ip=209.85.214.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="hwGkXK96" Received: by mail-pl1-f174.google.com with SMTP id d9443c01a7336-271d1305ad7so70291725ad.2 for ; Mon, 29 Sep 2025 19:46:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1759200367; x=1759805167; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=9bGi3tzoowdq7F8N73OupFeSpGLIzMxuMKRIXFA+k0I=; b=hwGkXK964jC/canEa9GRr+8Rz80k7tmoFbMRAjmWKCoy0wnhyb2pbJgh+CDiSogsnE kVYF4xh6GPJFlXzbukXYpYqaedYXSIPe8bTdG8/EtQPR1fn7GtMfZpIX1t/BqWDg4Cdi +IDutdGy9Lpnaaoe6P/8HAV1SNCnE+TookOrOUANCQw8pbWAg2rFtJ4OTh5DLu8P18Cv 0KlvfGcV6hKT2aCckGU/xhEyyCPUZKbRLMkchmDq1BlA4xj2b6gw0ci8XWzqtAOpyx+y XPQImQWclIvHxP+ZzhYxcYoTwJW2S3bGyepBhTSXdYd1OciCwnOAKjpN9so/mIAj4ciY fVgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759200367; x=1759805167; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=9bGi3tzoowdq7F8N73OupFeSpGLIzMxuMKRIXFA+k0I=; b=jlOt/9Pr0owG2qqJZTgThtstCI5o1pSAzmcD4JkyN+IFAF53h/OLOr7w8lpPR81AG4 w0Mg6KuLNLDC4TzhTEs1xz3aoSisE8AUIoQtVXfGEhVu9RfZ7k8cg0Fw/ye5okRgn12m BRwc0w5yoY1Qq5R5ek1ZXXZCNn3pcwQvclRNvqaRgHnYEwl3mv+6d3XV6UIde9jFN29k VDoHQnaW2S+1mFW9xinD8pXzQU3gpFZ9zDl7YUnSXovcFaNoCTOUkez0HSTkgTML27yg fPYStGxdk07kqp3v5VQRtpFqI8F+eV3viMKjpHwAfbMpzv+zEJ1CHFChBtxs8jVef8Fz nRqQ== X-Forwarded-Encrypted: i=1; AJvYcCUviNu6xbdCn2W+OZ0n1TKQnvmHHk38fX34jggmP4x/82m7kyDr1pXoTOlscQ+KLkqmBINo4Y17NkEUatU=@vger.kernel.org X-Gm-Message-State: AOJu0Yxm7QAC3kC3ccxUVJQfQyX7bHbjRVQ5WfOWkenlcVrH49SoMd1M wgMW1yK8QCWArAi7VQxtqiMAGhIERO+cYf8g5mqVNvaiyt5s29Id54Qw X-Gm-Gg: ASbGncvFzPKAMvbL2AiQEt7qpwVmr3nwZcTDlTu+LATpYgXknfcRBxcA/ZI7Po9W+Eo qx0soinwnIxv5FAFzl7AC+vo3eQ8wblygIT5/xCfnm9pDNf0mYlMmi3UfLKZqrD4QvBsHWdt55u P6kjlbFMKzFDwaY6MlENLQpGRGUeY5ljIoOftubkpgS/3zKbHsG8u6xDgAIFGOemNooq8dZQmmn CyeEbvPAumGvewBRSUdraKO9Vv/yMf9fTnsEKSxbVsptA4KVdR3j3bJRKLLYXDcaWmh9zITjVLm MBSu6wblet7K/ojlFLh8M2YIuVjxmxhSnk42p1ErBKL8FeFCAAOCcTfX6g09xLeRnYt7PwtE0NS RXtOyUQdWtDjqjpns90rlWIXqq/IkPZWJbSS8kYcio28g+Ndd0cwCZ3Ea6HjqzxvvAvodZwMKPk 8i X-Google-Smtp-Source: AGHT+IFoiKVgZ7dg//OuhMhm/v5is/JKhf1lFey82Z71vebCWO6695PgeZ0Sr0qvIyrxcwzNDU9ePQ== X-Received: by 2002:a17:903:2ace:b0:268:f83a:835a with SMTP id d9443c01a7336-27ed4a64485mr174059075ad.60.1759200367052; Mon, 29 Sep 2025 19:46:07 -0700 (PDT) Received: from localhost ([45.142.167.196]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-27ed6881fcasm144484295ad.93.2025.09.29.19.46.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Sep 2025 19:46:06 -0700 (PDT) From: Jinchao Wang To: Andrew Morton , Masami Hiramatsu , Peter Zijlstra , Mike Rapoport , Alexander Potapenko , Randy Dunlap , Marco Elver , Jonathan Corbet , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , "Liang, Kan" , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Suren Baghdasaryan , Michal Hocko , Nathan Chancellor , Nick Desaulniers , Bill Wendling , Justin Stitt , Kees Cook , Alice Ryhl , Sami Tolvanen , Miguel Ojeda , Masahiro Yamada , Rong Xu , Naveen N Rao , David Kaplan , Andrii Nakryiko , Jinjie Ruan , Nam Cao , 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 , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , kasan-dev@googlegroups.com, "David S. Miller" , Mathieu Desnoyers , linux-trace-kernel@vger.kernel.org Cc: Jinchao Wang Subject: [PATCH v6 22/23] docs: add KStackWatch document Date: Tue, 30 Sep 2025 10:43:43 +0800 Message-ID: <20250930024402.1043776-23-wangjinchao600@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20250930024402.1043776-1-wangjinchao600@gmail.com> References: <20250930024402.1043776-1-wangjinchao600@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Add documentation for KStackWatch under Documentation/. It provides an overview, main features, usage details, configuration parameters, and example scenarios with test cases. The document also explains how to locate function offsets and interpret logs. Signed-off-by: Jinchao Wang --- Documentation/dev-tools/index.rst | 1 + Documentation/dev-tools/kstackwatch.rst | 314 ++++++++++++++++++++++++ 2 files changed, 315 insertions(+) create mode 100644 Documentation/dev-tools/kstackwatch.rst diff --git a/Documentation/dev-tools/index.rst b/Documentation/dev-tools/in= dex.rst index 65c54b27a60b..45eb828d9d65 100644 --- a/Documentation/dev-tools/index.rst +++ b/Documentation/dev-tools/index.rst @@ -31,6 +31,7 @@ Documentation/process/debugging/index.rst kcsan kfence kselftest + kstackwatch kunit/index ktap checkuapi diff --git a/Documentation/dev-tools/kstackwatch.rst b/Documentation/dev-to= ols/kstackwatch.rst new file mode 100644 index 000000000000..7100248bc130 --- /dev/null +++ b/Documentation/dev-tools/kstackwatch.rst @@ -0,0 +1,314 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D +Kernel Stack Watch (KStackWatch) +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D + +Overview +=3D=3D=3D=3D=3D=3D=3D=3D + +KStackWatch is a lightweight debugging tool designed 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 call stack. + +Main features: + +* Immediate and precise detection +* Supports concurrent calls to the watched function +* Lockless design, usable in any context +* Depth filter for recursive calls +* Minimal impact on reproducibility +* Flexible configuration with key=3Dval syntax + +Usage +=3D=3D=3D=3D=3D + +KStackWatch is configured through */sys/kernel/debug/kstackwatch/config* u= sing a +key=3Dvalue format. Both long and short forms are supported. Writing an em= pty +string disables the watch. + +.. code-block:: bash + + # long form + echo func_name=3D? func_offset=3D? ... > /sys/kernel/debug/kstackwatch/co= nfig + + # short form + echo fn=3D? fo=3D? ... > /sys/kernel/debug/kstackwatch/config + + # disable + echo > /sys/kernel/debug/kstackwatch/config + +The func_name and the func_offset where the watchpoint should be placed mu= st be +known. This information can be obtained from *objdump* or other tools. + +Required parameters +-------------------- + ++--------------+--------+-----------------------------------------+ +| Parameter | Short | Description | ++=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D+=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ +| func_name | fn | Name of the target function | ++--------------+--------+-----------------------------------------+ +| func_offset | fo | Instruction pointer offset | ++--------------+--------+-----------------------------------------+ + +Optional parameters +-------------------- + +Default 0 and can be omitted. +Both decimal and hexadecimal are supported. + ++--------------+--------+------------------------------------------------+ +| Parameter | Short | Description | ++=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D+=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ +| depth | dp | Recursion depth filter | ++--------------+--------+------------------------------------------------+ +| max_watch | mw | Maximum number of concurrent watchpoints | +| | | (default 0, capped by available hardware | +| | | breakpoints) | ++--------------+--------+------------------------------------------------+ +| sp_offset | so | Watching addr offset from stack pointer | ++--------------+--------+------------------------------------------------+ +| watch_len | wl | Watch length in bytes (1, 2, 4, 8, or 0), | +| | | 0 means automatically watch the stack canary | +| | | and ignore the sp_offset parameter | ++--------------+--------+------------------------------------------------+ + +Workflow Example +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +Silent corruption +----------------- + +Consider *test3* in *kstackwatch_test.sh*. Run it directly: + +.. code-block:: bash + + echo test3 >/sys/kernel/debug/kstackwatch/test + +Sometimes, *test_mthread_victim()* may report as unhappy: + +.. code-block:: bash + + [ 7.807082] kstackwatch_test: victim[0][11]: unhappy buf[8]=3D0xabcdab= cd + +Its source code is: + +.. code-block:: c + + static void test_mthread_victim(int thread_id, int seq_id, u64 start_ns) + { + ulong buf[BUFFER_SIZE]; + + for (int j =3D 0; j < BUFFER_SIZE; j++) + buf[j] =3D 0xdeadbeef + seq_id; + + if (start_ns) + silent_wait_us(start_ns, VICTIM_MINIOR_WAIT_NS); + + for (int j =3D 0; j < BUFFER_SIZE; j++) { + if (buf[j] !=3D (0xdeadbeef + seq_id)) { + pr_warn("victim[%d][%d]: unhappy buf[%d]=3D0x%lx\n", + thread_id, seq_id, j, buf[j]); + return; + } + } + + pr_info("victim[%d][%d]: happy\n", thread_id, seq_id); + } + +From the source code, the report indicates buf[8] was unexpectedly modifie= d, +a case of silent corruption. + +Configuration +------------- + +Since buf[8] is the corrupted variable, the following configuration shows +how to use KStackWatch to detect its corruption. + +func_name +~~~~~~~~~~~ + +As seen, buf[8] is initialized and modified in *test_mthread_victim*\(\) , +which sets *func_name*. + +func_offset & sp_offset +~~~~~~~~~~~~~~~~~~~~~~~~~ +The watchpoint should be set after the assignment and as close as +possible, which sets *func_offset*. + +The watchpoint should be set to watch buf[8], which sets *sp_offset*. + +Use the objdump output to disassemble the function: + +.. code-block:: bash + + objdump -S --disassemble=3Dtest_mthread_victim vmlinux + +A shortened output is: + +.. code-block:: text + + static void test_mthread_victim(int thread_id, int seq_id, u64 start_ns) + { + ffffffff815cb4e0: e8 5b 9b ca ff call ffffffff81275040 <= __fentry__> + ffffffff815cb4e5: 55 push %rbp + ffffffff815cb4e6: 53 push %rbx + ffffffff815cb4e7: 48 81 ec 08 01 00 00 sub $0x108,%rsp + ffffffff815cb4ee: 89 fd mov %edi,%ebp + ffffffff815cb4f0: 89 f3 mov %esi,%ebx + ffffffff815cb4f2: 49 89 d0 mov %rdx,%r8 + ffffffff815cb4f5: 65 48 8b 05 0b cb 80 mov %gs:0x280cb0b(%rip= ),%rax # ffffffff83dd8008 <__stack_chk_guard> + ffffffff815cb4fc: 02 + ffffffff815cb4fd: 48 89 84 24 00 01 00 mov %rax,0x100(%rsp) + ffffffff815cb504: 00 + ffffffff815cb505: 31 c0 xor %eax,%eax + ulong buf[BUFFER_SIZE]; + ffffffff815cb507: 48 89 e2 mov %rsp,%rdx + ffffffff815cb50a: b9 20 00 00 00 mov $0x20,%ecx + ffffffff815cb50f: 48 89 d7 mov %rdx,%rdi + ffffffff815cb512: f3 48 ab rep stos %rax,%es:(%rdi) + + for (int j =3D 0; j < BUFFER_SIZE; j++) + ffffffff815cb515: eb 10 jmp ffffffff815cb527 <= test_mthread_victim+0x47> + buf[j] =3D 0xdeadbeef + seq_id; + ffffffff815cb517: 8d 93 ef be ad de lea -0x21524111(%rbx),= %edx + ffffffff815cb51d: 48 63 c8 movslq %eax,%rcx + ffffffff815cb520: 48 89 14 cc mov %rdx,(%rsp,%rcx,8) + ffffffff815cb524: 83 c0 01 add $0x1,%eax + ffffffff815cb527: 83 f8 1f cmp $0x1f,%eax + ffffffff815cb52a: 7e eb jle ffffffff815cb517 <= test_mthread_victim+0x37> + if (start_ns) + ffffffff815cb52c: 4d 85 c0 test %r8,%r8 + ffffffff815cb52f: 75 21 jne ffffffff815cb552 <= test_mthread_victim+0x72> + silent_wait_us(start_ns, VICTIM_MINIOR_WAIT_NS); + ... + ffffffff815cb571: 48 8b 84 24 00 01 00 mov 0x100(%rsp),%rax + ffffffff815cb579: 65 48 2b 05 87 ca 80 sub %gs:0x280ca87(%rip= ),%rax # ffffffff83dd8008 <__stack_chk_guard> + ... + ffffffff815cb5a1: eb ce jmp ffffffff815cb571 <= test_mthread_victim+0x91> + } + ffffffff815cb5a3: e8 d8 86 f1 00 call ffffffff824e3c80 <= __stack_chk_fail> + + +func_offset +^^^^^^^^^^^ + +The function begins at ffffffff815cb4e0. The *buf* array is initialized in= a loop. +The instruction storing values into the array is at ffffffff815cb520, and = the +first instruction after the loop is at ffffffff815cb52c. + +Because KStackWatch uses *kprobe.post_handler*, the watchpoint can be +set right after ffffffff815cb520. However, this will cause false positive +because the watchpoint is active before buf[8] is assigned. + +An alternative is to place the watchpoint at ffffffff815cb52c, right +after the loop. This avoids false positives but leaves a small window +for false negatives. + +In this document, ffffffff815cb52c is chosen for cleaner logs. If false +negatives are suspected, repeat the test to catch the corruption. + +The required offset is calculated from the function start: + +*func_offset* is 0x4c (ffffffff815cb52c - ffffffff815cb4e0). + +sp_offset +^^^^^^^^^^^ + +From the disassembly, the buf array is at the top of the stack, +meaning buf =3D=3D rsp. Therefore, buf[8] sits at rsp + 8 * sizeof(ulong) = =3D +rsp + 64. Thus, *sp_offset* is 64. + +Other parameters +~~~~~~~~~~~~~~~~~~ + +* *depth* is 0, as test_mthread_victim is not recursive +* *max_watch* is 0 to use all available hwbps +* *watch_len* is 8, the size of a ulong on x86_64 + +Parameters with a value of 0 can be omitted as defaults. + +Configure the watch: + +.. code-block:: bash + + echo "fn=3Dtest_mthread_victim fo=3D0x4c so=3D64 wl=3D8" > /sys/kernel/de= bug/kstackwatch/config + +Now rerun the test: + +.. code-block:: bash + + echo test3 >/sys/kernel/debug/kstackwatch/test + +The dmesg log shows: + +.. code-block:: text + + [ 7.607074] kstackwatch: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D KStackWatch: C= aught stack corruption =3D=3D=3D=3D=3D=3D=3D + [ 7.607077] kstackwatch: config fn=3Dtest_mthread_victim fo=3D0x4c so= =3D64 wl=3D8 + [ 7.607080] CPU: 2 UID: 0 PID: 347 Comm: corrupting Not tainted 6.17.0= -rc7-00022-g90270f3db80a-dirty #509 PREEMPT(voluntary) + [ 7.607083] Call Trace: + [ 7.607084] <#DB> + [ 7.607085] dump_stack_lvl+0x66/0xa0 + [ 7.607091] ksw_watch_handler.part.0+0x2b/0x60 + [ 7.607094] ksw_watch_handler+0xba/0xd0 + [ 7.607095] ? test_mthread_corrupting+0x48/0xd0 + [ 7.607097] ? kthread+0x10d/0x210 + [ 7.607099] ? ret_from_fork+0x187/0x1e0 + [ 7.607102] ? ret_from_fork_asm+0x1a/0x30 + [ 7.607105] __perf_event_overflow+0x154/0x570 + [ 7.607108] perf_bp_event+0xb4/0xc0 + [ 7.607112] ? look_up_lock_class+0x59/0x150 + [ 7.607115] hw_breakpoint_exceptions_notify+0xf7/0x110 + [ 7.607117] notifier_call_chain+0x44/0x110 + [ 7.607119] atomic_notifier_call_chain+0x5f/0x110 + [ 7.607121] notify_die+0x4c/0xb0 + [ 7.607123] exc_debug_kernel+0xaf/0x170 + [ 7.607126] asm_exc_debug+0x1e/0x40 + [ 7.607127] RIP: 0010:test_mthread_corrupting+0x48/0xd0 + [ 7.607129] Code: c7 80 0a 24 83 e8 48 f1 f1 00 48 85 c0 74 dd eb 30 b= b 00 00 00 00 eb 59 48 63 c2 48 c1 e0 03 48 03 03 be cd ab cd ab 48 89 30 <= 83> c2 01 b8 20 00 00 00 29 c8 39 d0 7f e0 48 8d 7b 10 e8 d1 86 d4 + [ 7.607130] RSP: 0018:ffffc90000acfee0 EFLAGS: 00000286 + [ 7.607132] RAX: ffffc90000a13de8 RBX: ffff888102d57580 RCX: 000000000= 0000008 + [ 7.607132] RDX: 0000000000000008 RSI: 00000000abcdabcd RDI: ffffc9000= 0acfe00 + [ 7.607133] RBP: ffff8881085bc800 R08: 0000000000000001 R09: 000000000= 0000000 + [ 7.607133] R10: 0000000000000001 R11: 0000000000000000 R12: ffff88810= 5398000 + [ 7.607134] R13: ffff8881085bc800 R14: ffffffff815cb660 R15: 000000000= 0000000 + [ 7.607134] ? __pfx_test_mthread_corrupting+0x10/0x10 + [ 7.607137] + [ 7.607138] + [ 7.607138] kthread+0x10d/0x210 + [ 7.607140] ? __pfx_kthread+0x10/0x10 + [ 7.607141] ret_from_fork+0x187/0x1e0 + [ 7.607143] ? __pfx_kthread+0x10/0x10 + [ 7.607144] ret_from_fork_asm+0x1a/0x30 + [ 7.607147] + [ 7.607147] kstackwatch: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D KStackWatch End =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D + [ 7.807082] kstackwatch_test: victim[0][11]: unhappy buf[8]=3D0xabcdab= cd + +The line ``RIP: 0010:test_mthread_corrupting+0x48/0xd0`` shows the exact +location where the corruption occurred. Now that the ``corrupting()`` func= tion has +been identified, it is straightforward to trace back to ``buggy()`` and fi= x the bug. + + +More usage examples and corruption scenarios are provided in +``kstackwatch_test.sh`` and ``mm/kstackwatch/test.c``. + +Limitations +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +* Limited by available hardware breakpoints +* Only one function can be watched at a time +* Canary search limited to 128 * sizeof(ulong) from the current stack + pointer. This is sufficient for most cases, but has three limitations: + + - If the stack frame is larger, the search may fail. + - If the function does not have a canary, the search may fail. + - If stack memory occasionally contains the same value as the canary, + it may be incorrectly matched. + + In these cases, the user can provide the canary location using + ``sp_offset``, or treat any memory in the function prologue + as the canary. --=20 2.43.0