* [BUG] KCSAN cannot find frame in stack trace
@ 2026-10-30 0:10 Paul E. McKenney
2026-10-30 8:33 ` Marco Elver
0 siblings, 1 reply; 3+ messages in thread
From: Paul E. McKenney @ 2026-10-30 0:10 UTC (permalink / raw)
To: Marco Elver, Ingo Molnar, Peter Zijlstra, Juri Lelli,
Vincent Guittot, Kees Cook
Cc: Dmitry Vyukov, Dietmar Eggemann, Steven Rostedt, Ben Segall,
Mel Gorman, Valentin Schneider, K Prateek Nayak, kasan-dev,
linux-kernel, linux-mm
Hello!
I am seeing the following (very) intermittent spat when running
the rcutorture script torture.sh on recent -next (starting about
next-20261014) with KCSAN enabled:
[ 0.312250] ------------[ cut here ]------------
[ 0.312256] Cannot find frame for arch_dup_task_struct+0x40/0x154 in stack trace
[ 0.312324] WARNING: kernel/kcsan/report.c:344 at sanitize_stack_entries+0x120/0x12c, CPU#16: swapper/16/0
[ 0.312349] Modules linked in:
[ 0.312358] CPU: 16 UID: 0 PID: 0 Comm: swapper/16 Not tainted 7.3.0-rc7-next-20261014-00001-gc88f750a9fe1 #17994 PREEMPT(full)
[ 0.312367] Hardware name: linux,dummy-virt (DT)
[ 0.312370] pstate: 600003c5 (nZCv DAIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 0.312378] pc : sanitize_stack_entries+0x120/0x12c
[ 0.312385] lr : sanitize_stack_entries+0x120/0x12c
[ 0.312392] sp : ffff800080283900
[ 0.312394] x29: ffff800080283920 x28: ffff000005f79550 x27: ffff000005f78000
[ 0.312404] x26: 0000000000000008 x25: ffffc75ad7c6d414 x24: ffff800080283998
[ 0.312413] x23: ffffc75ad7c96900 x22: 0000000000000008 x21: ffffc75ad7c6d454
[ 0.312423] x20: 0000000000000008 x19: ffff8000802839a0 x18: 0000000000000000
[ 0.312431] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000001
[ 0.312440] x14: ffff000005f794f0 x13: ffffc75adac1ea88 x12: ffffffffffffffff
[ 0.312449] x11: ffffc75adac1eae8 x10: 0000000000000001 x9 : e761494156778100
[ 0.312459] x8 : e761494156778100 x7 : 6563617274206b63 x6 : 63617473206e6920
[ 0.312468] x5 : 0000000000000000 x4 : ffffc75adc9fc468 x3 : 00000000000005e3
[ 0.312477] x2 : 0000000000000004 x1 : 0000000000000008 x0 : ffff000005f78008
[ 0.312486] Call trace:
[ 0.312489] sanitize_stack_entries+0x120/0x12c (P)
[ 0.312499] print_report+0x84/0x488
[ 0.312507] kcsan_report_known_origin+0x14c/0x1ec
[ 0.312516] kcsan_setup_watchpoint+0x578/0x864
[ 0.312525] __kcsan_check_access+0x1ec/0x1f8
[ 0.312535] do_raw_spin_lock+0xa4/0x1c4
[ 0.312547] _raw_spin_lock+0x70/0x88
[ 0.312559] rcutree_report_cpu_starting+0x1ac/0x4b8
[ 0.312568] secondary_start_kernel+0xe8/0x28c
[ 0.312577] __secondary_switched+0xc0/0xc4
[ 0.312586] irq event stamp: 0
[ 0.312588] hardirqs last enabled at (0): [<0000000000000000>] 0x0
[ 0.312594] hardirqs last disabled at (0): [<ffffc75ad7d6a34c>] copy_process+0x9a8/0x18a8
[ 0.312604] softirqs last enabled at (0): [<ffffc75ad7d6a35c>] copy_process+0x9b8/0x18a8
[ 0.312612] softirqs last disabled at (0): [<0000000000000000>] 0x0
[ 0.312617] ---[ end trace 0000000000000000 ]---
[ 0.312641] ==================================================================
This is the code at line 344 of kernel/kcsan/report.c:
/* Should not happen; the resulting stack trace is likely misleading. */
WARN_ONCE(1, "Cannot find frame for %pS in stack trace", (void *)ip);
This does not happen often enough for reasonable bisection. However, the
alleged fix below does seem to prevent this from happening. This alleged
fix should of course be considered to be part of the bug report: I am
*not* claiming that it is a proper fix.
The diagnosis sounds plausible to me, but perhaps not to those who
understand the affected code better than I do. And I don't know why
this wouldn't have been showing up earlier.
Thoughts?
Thanx, Paul
------------------------------------------------------------------------
LLM alleged fix:
------------------------------------------------------------------------
kcsan: reset per-task KCSAN state in dup_task_struct
KCSAN's per-task state (struct kcsan_ctx) is copied verbatim from parent
to child by arch_dup_task_struct(), and is never reinitialized on fork.
With CONFIG_KCSAN_WEAK_MEMORY, this leaks the parent's in-flight
reorder_access (and kcsan_stack_depth) into the child.
In particular, __tsan_memcpy() runs check_access() before the real copy,
so when fork_idle() copies a task_struct, the parent first records the
task_struct-sized write with ip in arch_dup_task_struct as its reorder
access, and the subsequent memcpy then copies that very reorder entry
into the child. The parent's entry is cleared on function exit, but the
child boots with the stale entry still valid (its inherited stack depth
never returns through the parent's call chain).
On arm64 secondary boot this produces a false-positive report: the stale
write "replays" against the idle task's own read of
current_thread_info()->cpu in raw_smp_processor_id() (via
arch_timer_evtstrm_available() during a watchpoint delay). At report
time replace_stack_entry() then warns with "Cannot find frame for
arch_dup_task_struct+0x40 in stack trace", because the reorder ip has no
frame on the child's secondary_start_kernel stack.
Fix by resetting the child's KCSAN state in generic dup_task_struct(),
alongside the existing kcov/kmsan initializers: zero kcsan_ctx, restore
the lazy-empty scoped_accesses list encoding used by init_task, and zero
kcsan_stack_depth and kcsan_save_irqtrace.
Fixes: 69562e4983d93 ("kcsan: Add core support for a subset of weak memory modeling")
---
include/linux/kcsan.h | 10 ++++++++++
kernel/fork.c | 2 ++
kernel/kcsan/core.c | 19 +++++++++++++++++++
3 files changed, 31 insertions(+)
diff --git a/include/linux/kcsan.h b/include/linux/kcsan.h
--- a/include/linux/kcsan.h
+++ b/include/linux/kcsan.h
@@ -10,7 +10,9 @@
#ifndef _LINUX_KCSAN_H
#define _LINUX_KCSAN_H
#include <linux/kcsan-checks.h>
#include <linux/types.h>
+struct task_struct;
+
#ifdef CONFIG_KCSAN
@@ -62,14 +62,22 @@
};
/**
* kcsan_init - initialize KCSAN runtime
*/
void kcsan_init(void);
+/**
+ * kcsan_task_init - initialize KCSAN state for a new task
+ *
+ * @task: task to initialize.
+ */
+void kcsan_task_init(struct task_struct *task);
+
#else /* CONFIG_KCSAN */
static inline void kcsan_init(void) { }
+static inline void kcsan_task_init(struct task_struct *task) { }
#endif /* CONFIG_KCSAN */
#endif /* _LINUX_KCSAN_H */
diff --git a/kernel/fork.c b/kernel/fork.c
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -93,6 +93,7 @@
#include <linux/compiler.h>
#include <linux/sysctl.h>
#include <linux/kcov.h>
+#include <linux/kcsan.h>
#include <linux/livepatch.h>
#include <linux/thread_info.h>
#include <linux/kstack_erase.h>
@@ -986,7 +986,8 @@
tsk->worker_private = NULL;
kcov_task_init(tsk);
kmsan_task_create(tsk);
+ kcsan_task_init(tsk);
kmap_local_fork(tsk);
#ifdef CONFIG_FAULT_INJECTION
diff --git a/kernel/kcsan/core.c b/kernel/kcsan/core.c
--- a/kernel/kcsan/core.c
+++ b/kernel/kcsan/core.c
@@ -828,6 +828,25 @@
}
}
+void kcsan_task_init(struct task_struct *task)
+{
+ /*
+ * Drop per-task KCSAN state copied verbatim from the parent by
+ * arch_dup_task_struct(). A stale reorder_access would otherwise be
+ * replayed by the child in an unrelated call chain, causing
+ * false-positive reports and a "Cannot find frame ..." warning in
+ * replace_stack_entry().
+ */
+ memset(&task->kcsan_ctx, 0, sizeof(task->kcsan_ctx));
+ task->kcsan_ctx.scoped_accesses = (struct list_head){ LIST_POISON1, NULL };
+#ifdef CONFIG_KCSAN_WEAK_MEMORY
+ task->kcsan_stack_depth = 0;
+#endif
+#ifdef CONFIG_TRACE_IRQFLAGS
+ memset(&task->kcsan_save_irqtrace, 0, sizeof(task->kcsan_save_irqtrace));
+#endif
+}
+
/* === Exported interface =================================================== */
void kcsan_disable_current(void)
------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [BUG] KCSAN cannot find frame in stack trace
2026-10-30 0:10 [BUG] KCSAN cannot find frame in stack trace Paul E. McKenney
@ 2026-10-30 8:33 ` Marco Elver
2026-10-30 14:25 ` Paul E. McKenney
0 siblings, 1 reply; 3+ messages in thread
From: Marco Elver @ 2026-10-30 8:33 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Ingo Molnar, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Kees Cook, Dmitry Vyukov, Dietmar Eggemann, Steven Rostedt,
Ben Segall, Mel Gorman, Valentin Schneider, K Prateek Nayak,
kasan-dev, linux-kernel, linux-mm
On Thu, Oct 29, 2026 at 05:10PM -0700, Paul E. McKenney wrote:
> Hello!
>
> I am seeing the following (very) intermittent spat when running
> the rcutorture script torture.sh on recent -next (starting about
> next-20261014) with KCSAN enabled:
I think there's no reason why this should happen more often. Maybe the
torture testing or your system became better at exposing this?
[...]
> This is the code at line 344 of kernel/kcsan/report.c:
>
> /* Should not happen; the resulting stack trace is likely misleading. */
> WARN_ONCE(1, "Cannot find frame for %pS in stack trace", (void *)ip);
>
> This does not happen often enough for reasonable bisection. However, the
> alleged fix below does seem to prevent this from happening. This alleged
> fix should of course be considered to be part of the bug report: I am
> *not* claiming that it is a proper fix.
>
> The diagnosis sounds plausible to me, but perhaps not to those who
> understand the affected code better than I do. And I don't know why
> this wouldn't have been showing up earlier.
>
> Thoughts?
>
> Thanx, Paul
>
> ------------------------------------------------------------------------
> LLM alleged fix:
> ------------------------------------------------------------------------
>
> kcsan: reset per-task KCSAN state in dup_task_struct
Yes, it's very plausible and the stack-trace and WARN all line up.
We don't need to reset kcsan_save_irqtrace as that's guaranteed to be
overwritten before reading out again.
Updated fix below; it's basically identical, except for
kcsan_save_irqtrace. Let me know if I can either add your
SOB+Co-authored-by, or you send it out as a PATCH yourself.
Thanks,
-- Marco
------ >8 ------
From: Marco Elver <elver@google.com>
Date: Fri, 30 Oct 2026 00:46:03 +0000
Subject: [PATCH] kcsan: Reset per-task KCSAN state on fork
arch_dup_task_struct() copies the parent's task_struct verbatim, which
includes kcsan_ctx and kcsan_stack_depth; nothing reinitializes them for
the child.
With CONFIG_KCSAN_WEAK_MEMORY this leaks a live reorder_access: an
access whose simulated reordering is only valid until the parent returns
from the frame that performed it (tracked via kcsan_stack_depth and
cleared by __tsan_func_exit()). The child inherits both the entry and
the parent's stack depth, but never returns through the parent's frames,
so the entry is never invalidated and is replayed on every subsequent
check_access() of the child.
The most direct way to hit this is the copy itself: __tsan_memcpy()
runs check_access() on the destination before copying. If that access is
selected for a watchpoint, set_reorder_access() records it (ptr = the
child's task_struct, ip in arch_dup_task_struct()) in the parent's ctx,
and the memcpy then copies that entry into the child. For an idle task
created by fork_idle(), the stale access covers thread_info.flags, which
other CPUs frequently access, resulting in false positive reports and:
WARNING: kernel/kcsan/report.c:344 at sanitize_stack_entries+0x120/0x12c
Cannot find frame for arch_dup_task_struct+0x40/0x154 in stack trace
...
Call trace:
sanitize_stack_entries+0x120/0x12c (P)
print_report+0x84/0x488
kcsan_report_known_origin+0x14c/0x1ec
kcsan_setup_watchpoint+0x578/0x864
__kcsan_check_access+0x1ec/0x1f8
do_raw_spin_lock+0xa4/0x1c4
_raw_spin_lock+0x70/0x88
rcutree_report_cpu_starting+0x1ac/0x4b8
secondary_start_kernel+0xe8/0x28c
__secondary_switched+0xc0/0xc4
Reset the child's KCSAN state in dup_task_struct() after the copy,
alongside the existing kcov/kmsan initializers.
Reported-by: Paul E. McKenney <paulmck@kernel.org>
Link: https://lore.kernel.org/all/97f6213a-1dec-494e-96d1-abe546bce993@paulmck-laptop/
Fixes: 69562e4983d9 ("kcsan: Add core support for a subset of weak memory modeling")
Cc: stable@vger.kernel.org
Signed-off-by: Marco Elver <elver@google.com>
---
include/linux/kcsan.h | 10 ++++++++++
kernel/fork.c | 2 ++
kernel/kcsan/core.c | 16 ++++++++++++++++
3 files changed, 28 insertions(+)
diff --git a/include/linux/kcsan.h b/include/linux/kcsan.h
index c07c71f5ba4f..c7e9d15dd7bd 100644
--- a/include/linux/kcsan.h
+++ b/include/linux/kcsan.h
@@ -13,6 +13,8 @@
#include <linux/kcsan-checks.h>
#include <linux/types.h>
+struct task_struct;
+
#ifdef CONFIG_KCSAN
/*
@@ -66,9 +68,17 @@ struct kcsan_ctx {
*/
void kcsan_init(void);
+/**
+ * kcsan_task_init - initialize KCSAN state of a new task
+ *
+ * @task: task to initialize; must have been copied from its parent already.
+ */
+void kcsan_task_init(struct task_struct *task);
+
#else /* CONFIG_KCSAN */
static inline void kcsan_init(void) { }
+static inline void kcsan_task_init(struct task_struct *task) { }
#endif /* CONFIG_KCSAN */
diff --git a/kernel/fork.c b/kernel/fork.c
index 5ef413368912..62a096ca8dce 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -93,6 +93,7 @@
#include <linux/compiler.h>
#include <linux/sysctl.h>
#include <linux/kcov.h>
+#include <linux/kcsan.h>
#include <linux/livepatch.h>
#include <linux/thread_info.h>
#include <linux/kstack_erase.h>
@@ -986,6 +987,7 @@ static struct task_struct *dup_task_struct(struct task_struct *orig, int node)
kcov_task_init(tsk);
kmsan_task_create(tsk);
+ kcsan_task_init(tsk);
kmap_local_fork(tsk);
#ifdef CONFIG_FAULT_INJECTION
diff --git a/kernel/kcsan/core.c b/kernel/kcsan/core.c
index a3aa5e5b039d..d19d60ad007a 100644
--- a/kernel/kcsan/core.c
+++ b/kernel/kcsan/core.c
@@ -828,6 +828,22 @@ void __init kcsan_init(void)
}
}
+void kcsan_task_init(struct task_struct *task)
+{
+ /*
+ * arch_dup_task_struct() copies the parent's kcsan_ctx verbatim,
+ * including a reorder_access that is still live in the parent's frame
+ * (e.g. the write of the copy itself). The child never returns through
+ * that frame, so it would replay the stale access indefinitely, causing
+ * false positives and "Cannot find frame" warnings in replace_stack_entry().
+ */
+ memset(&task->kcsan_ctx, 0, sizeof(task->kcsan_ctx));
+ task->kcsan_ctx.scoped_accesses = (struct list_head){ LIST_POISON1, NULL };
+#ifdef CONFIG_KCSAN_WEAK_MEMORY
+ task->kcsan_stack_depth = 0;
+#endif
+}
+
/* === Exported interface =================================================== */
void kcsan_disable_current(void)
--
2.56.0.317.g454f8302e1-goog
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [BUG] KCSAN cannot find frame in stack trace
2026-10-30 8:33 ` Marco Elver
@ 2026-10-30 14:25 ` Paul E. McKenney
0 siblings, 0 replies; 3+ messages in thread
From: Paul E. McKenney @ 2026-10-30 14:25 UTC (permalink / raw)
To: Marco Elver
Cc: Ingo Molnar, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Kees Cook, Dmitry Vyukov, Dietmar Eggemann, Steven Rostedt,
Ben Segall, Mel Gorman, Valentin Schneider, K Prateek Nayak,
kasan-dev, linux-kernel, linux-mm
On Fri, Oct 30, 2026 at 08:33:55AM +0000, Marco Elver wrote:
> On Thu, Oct 29, 2026 at 05:10PM -0700, Paul E. McKenney wrote:
> > Hello!
> >
> > I am seeing the following (very) intermittent spat when running
> > the rcutorture script torture.sh on recent -next (starting about
> > next-20261014) with KCSAN enabled:
>
> I think there's no reason why this should happen more often. Maybe the
> torture testing or your system became better at exposing this?
Quite possibly. An effective test suite never stands still. ;-)
> [...]
> > This is the code at line 344 of kernel/kcsan/report.c:
> >
> > /* Should not happen; the resulting stack trace is likely misleading. */
> > WARN_ONCE(1, "Cannot find frame for %pS in stack trace", (void *)ip);
> >
> > This does not happen often enough for reasonable bisection. However, the
> > alleged fix below does seem to prevent this from happening. This alleged
> > fix should of course be considered to be part of the bug report: I am
> > *not* claiming that it is a proper fix.
> >
> > The diagnosis sounds plausible to me, but perhaps not to those who
> > understand the affected code better than I do. And I don't know why
> > this wouldn't have been showing up earlier.
> >
> > Thoughts?
> >
> > Thanx, Paul
> >
> > ------------------------------------------------------------------------
> > LLM alleged fix:
> > ------------------------------------------------------------------------
> >
> > kcsan: reset per-task KCSAN state in dup_task_struct
>
> Yes, it's very plausible and the stack-trace and WARN all line up.
Whew!!!
> We don't need to reset kcsan_save_irqtrace as that's guaranteed to be
> overwritten before reading out again.
>
> Updated fix below; it's basically identical, except for
> kcsan_save_irqtrace. Let me know if I can either add your
> SOB+Co-authored-by, or you send it out as a PATCH yourself.
Please do send it out. A Reported-by will more than suffice. It is
not like I put any of my own effort into that patch. ;-)
But if (and only if) your procedures absolutely require it:
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Thanx, Paul
> Thanks,
> -- Marco
>
> ------ >8 ------
>
> From: Marco Elver <elver@google.com>
> Date: Fri, 30 Oct 2026 00:46:03 +0000
> Subject: [PATCH] kcsan: Reset per-task KCSAN state on fork
>
> arch_dup_task_struct() copies the parent's task_struct verbatim, which
> includes kcsan_ctx and kcsan_stack_depth; nothing reinitializes them for
> the child.
>
> With CONFIG_KCSAN_WEAK_MEMORY this leaks a live reorder_access: an
> access whose simulated reordering is only valid until the parent returns
> from the frame that performed it (tracked via kcsan_stack_depth and
> cleared by __tsan_func_exit()). The child inherits both the entry and
> the parent's stack depth, but never returns through the parent's frames,
> so the entry is never invalidated and is replayed on every subsequent
> check_access() of the child.
>
> The most direct way to hit this is the copy itself: __tsan_memcpy()
> runs check_access() on the destination before copying. If that access is
> selected for a watchpoint, set_reorder_access() records it (ptr = the
> child's task_struct, ip in arch_dup_task_struct()) in the parent's ctx,
> and the memcpy then copies that entry into the child. For an idle task
> created by fork_idle(), the stale access covers thread_info.flags, which
> other CPUs frequently access, resulting in false positive reports and:
>
> WARNING: kernel/kcsan/report.c:344 at sanitize_stack_entries+0x120/0x12c
> Cannot find frame for arch_dup_task_struct+0x40/0x154 in stack trace
> ...
> Call trace:
> sanitize_stack_entries+0x120/0x12c (P)
> print_report+0x84/0x488
> kcsan_report_known_origin+0x14c/0x1ec
> kcsan_setup_watchpoint+0x578/0x864
> __kcsan_check_access+0x1ec/0x1f8
> do_raw_spin_lock+0xa4/0x1c4
> _raw_spin_lock+0x70/0x88
> rcutree_report_cpu_starting+0x1ac/0x4b8
> secondary_start_kernel+0xe8/0x28c
> __secondary_switched+0xc0/0xc4
>
> Reset the child's KCSAN state in dup_task_struct() after the copy,
> alongside the existing kcov/kmsan initializers.
>
> Reported-by: Paul E. McKenney <paulmck@kernel.org>
> Link: https://lore.kernel.org/all/97f6213a-1dec-494e-96d1-abe546bce993@paulmck-laptop/
> Fixes: 69562e4983d9 ("kcsan: Add core support for a subset of weak memory modeling")
> Cc: stable@vger.kernel.org
> Signed-off-by: Marco Elver <elver@google.com>
> ---
> include/linux/kcsan.h | 10 ++++++++++
> kernel/fork.c | 2 ++
> kernel/kcsan/core.c | 16 ++++++++++++++++
> 3 files changed, 28 insertions(+)
>
> diff --git a/include/linux/kcsan.h b/include/linux/kcsan.h
> index c07c71f5ba4f..c7e9d15dd7bd 100644
> --- a/include/linux/kcsan.h
> +++ b/include/linux/kcsan.h
> @@ -13,6 +13,8 @@
> #include <linux/kcsan-checks.h>
> #include <linux/types.h>
>
> +struct task_struct;
> +
> #ifdef CONFIG_KCSAN
>
> /*
> @@ -66,9 +68,17 @@ struct kcsan_ctx {
> */
> void kcsan_init(void);
>
> +/**
> + * kcsan_task_init - initialize KCSAN state of a new task
> + *
> + * @task: task to initialize; must have been copied from its parent already.
> + */
> +void kcsan_task_init(struct task_struct *task);
> +
> #else /* CONFIG_KCSAN */
>
> static inline void kcsan_init(void) { }
> +static inline void kcsan_task_init(struct task_struct *task) { }
>
> #endif /* CONFIG_KCSAN */
>
> diff --git a/kernel/fork.c b/kernel/fork.c
> index 5ef413368912..62a096ca8dce 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -93,6 +93,7 @@
> #include <linux/compiler.h>
> #include <linux/sysctl.h>
> #include <linux/kcov.h>
> +#include <linux/kcsan.h>
> #include <linux/livepatch.h>
> #include <linux/thread_info.h>
> #include <linux/kstack_erase.h>
> @@ -986,6 +987,7 @@ static struct task_struct *dup_task_struct(struct task_struct *orig, int node)
>
> kcov_task_init(tsk);
> kmsan_task_create(tsk);
> + kcsan_task_init(tsk);
> kmap_local_fork(tsk);
>
> #ifdef CONFIG_FAULT_INJECTION
> diff --git a/kernel/kcsan/core.c b/kernel/kcsan/core.c
> index a3aa5e5b039d..d19d60ad007a 100644
> --- a/kernel/kcsan/core.c
> +++ b/kernel/kcsan/core.c
> @@ -828,6 +828,22 @@ void __init kcsan_init(void)
> }
> }
>
> +void kcsan_task_init(struct task_struct *task)
> +{
> + /*
> + * arch_dup_task_struct() copies the parent's kcsan_ctx verbatim,
> + * including a reorder_access that is still live in the parent's frame
> + * (e.g. the write of the copy itself). The child never returns through
> + * that frame, so it would replay the stale access indefinitely, causing
> + * false positives and "Cannot find frame" warnings in replace_stack_entry().
> + */
> + memset(&task->kcsan_ctx, 0, sizeof(task->kcsan_ctx));
> + task->kcsan_ctx.scoped_accesses = (struct list_head){ LIST_POISON1, NULL };
> +#ifdef CONFIG_KCSAN_WEAK_MEMORY
> + task->kcsan_stack_depth = 0;
> +#endif
> +}
> +
> /* === Exported interface =================================================== */
>
> void kcsan_disable_current(void)
> --
> 2.56.0.317.g454f8302e1-goog
>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-10-30 14:25 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-10-30 0:10 [BUG] KCSAN cannot find frame in stack trace Paul E. McKenney
2026-10-30 8:33 ` Marco Elver
2026-10-30 14:25 ` Paul E. McKenney
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®