[PATCH v3 0/2] x86/fred: Fix stack depot exhaustion on FRED systems

[PATCH v3 0/2] x86/fred: Fix stack depot exhaustion on FRED systems

[Yuanhe Shu]

FRED replaces the IDT event entry stubs with asm_fred_entrypoint_user and
asm_fred_entrypoint_kernel, which live in .noinstr.text.  The IDT stubs
are the only code covered by __irqentry_text_start..__irqentry_text_end,
which in_irqentry_text() uses to find where an event entered the kernel.
With FRED the detection fails, filter_irq_stacks() no longer truncates
event stacks, and every trace saved from interrupt or exception context
by stack depot users (KASAN alloc/free tracking, SLUB object tracking,
...) becomes a unique combination of "event path x arbitrarily
interrupted context".  The depot grows without bound until it is
exhausted.

What we saw: a FRED-capable dual-socket system with KASAN (generic,
inline) and SLUB object tracking enabled hit the limit on both sockets
roughly 80 minutes after boot,

  Stack depot reached limit capacity
  WARNING: CPU: 286 PID: 128614 at lib/stackdepot.c:271 depot_alloc_stack+0x158/0x170

after which KASAN and SLUB stack tracking silently stop recording (new
traces get handle 0) until reboot.  The recorded traces confirmed the
mechanism: interrupt side traces ran through asm_fred_entrypoint_kernel
and continued into the frames of the interrupted task.

Patch 1 adds an optional arch_in_event_entry_text() hook to the generic
entry text check, and renames that check from in_irqentry_text() to
in_event_entry_text() since neither it nor the ranges it tests are
necessarily irq-only; no behavior change by itself.  Patch 2
implements it for x86 by bracketing the FRED entry text with
__fred_entry_text_start/end, the same way the IDT stubs are bracketed,
and reporting that range from <asm/sections.h>.

Unlike arm64 and s390, which hit the same symptom and could fix it by
placing their interrupt entry code in .irqentry.text, x86 has no such
section: it emits the markers as labels around the sequentially laid out
IDT stubs and defines __irq_entry to __invalid_section so that nothing
can land in that section.  The FRED entry points therefore cannot be
brought inside the existing range, and a second one has to be reported;
see patch 2 for the details.

Testing:

  - Build-tested on mainline: full vmlinux builds and link with
    CONFIG_X86_FRED=y, CONFIG_X86_KERNEL_IBT=y and KASAN (generic,
    inline), with and without CONFIG_KVM_INTEL=y, and with
    CONFIG_X86_FRED=n so that the generic fallback is used; objtool link
    stage clean.
  - Runtime-tested by backporting both patches to the affected kernel (a
    6.6 based debug build) and rebooting that system with an unchanged
    command line: traces recorded from FRED event context now end at
    asm_fred_entrypoint_kernel instead of continuing into the
    interrupted task, and the pool count levels off at ~1230 pools
    within minutes of boot instead of reaching the 8192 pool limit.

Reproducing on current upstream:

  - On FRED hardware, any KASAN or SLUB_DEBUG kernel; on v6.17 and
    later, boot with stack_depot_max_pools=1024 to bring the
    exhaustion warning up in minutes instead of hours, and watch the
    pool count in /sys/kernel/debug/stackdepot/stats grow
    monotonically without the fix and converge with it.
  - Without FRED hardware, the KVM VMX interrupt forwarding path
    (CONFIG_X86_FRED=y + CONFIG_KVM_INTEL) exercises the new filtering
    as well, see patch 2.

Both patches carry the same Fixes: tag and are Cc'ed to stable, and 2/2
uses the hook added by 1/2, so they need to be applied together.

Changes in v3:

  - 1/2: drop the x86 details from the generic comment and phrase it as an
    instruction for future arch maintainers (Dave Hansen)
  - 1/2: restore Bradley Morgan's Reviewed-by - he confirmed the tag still
    holds for the reworked version
  - 2/2: state the caveat that the range cannot tell interrupt entry and
    syscall entry apart here rather than in the generic comment

Changes in v2:

  - 1/2: drop the new ARCH_HAS_IN_IRQENTRY_TEXT Kconfig symbol and use the
    #ifndef macro override pattern instead, with the fallback next to its
    only user in kernel/stacktrace.c (Peter Zijlstra)
  - 1/2: rename in_irqentry_text() to in_event_entry_text() and name the
    hook after it - the ranges are not necessarily irq-only; on x86 they
    cover the exception entry stubs too (Peter Zijlstra)
  - 1/2: carry the same Fixes: tag as 2/2 (Andrew Morton)
  - 1/2: drop Bradley Morgan's Reviewed-by since the patch changed
    materially
  - 2/2: implement the hook as a static inline in <asm/sections.h> next to
    the markers it tests, instead of a Kconfig gated function in
    arch/x86/kernel/stacktrace.c; arch/x86/Kconfig is no longer touched
  - 2/2: spell out, in the changelog and in a comment on the hook, why the
    range covering the ring 3 entry point, and therefore syscalls, does not
    change any trace (Peter Zijlstra)
  - 2/2: add Reported-by for Xiang Zheng, who found the exhaustion

v1: https://lore.kernel.org/r/20260827150022.1618235-1-xiangzao@linux.alibaba.com
v2: https://lore.kernel.org/r/20260831120221.2874445-1-xiangzao@linux.alibaba.com

Yuanhe Shu (2):
  stacktrace: Provide arch_in_event_entry_text() hook
  x86/fred: Fix stack depot filtering of FRED event stacks

 arch/x86/entry/entry_64_fred.S  | 14 ++++++++++++++
 arch/x86/include/asm/sections.h | 24 ++++++++++++++++++++++++
 kernel/stacktrace.c             | 19 ++++++++++++++++---
 3 files changed, 54 insertions(+), 3 deletions(-)


base-commit: 45c13f3f9e3bb15fd89ff2864c6f627a3b4b4229
-- 
2.43.7

[PATCH v3 1/2] stacktrace: Provide arch_in_event_entry_text() hook

[Yuanhe Shu]

in_irqentry_text() decides whether a stack address belongs to interrupt
entry code by checking the .irqentry.text and .softirqentry.text section
ranges.  filter_irq_stacks() uses it to truncate interrupt stacks at the
entry point, which stack depot depends on to deduplicate them: traces
that continue past the interrupt entry lead to unbounded depot growth,
see commit e94006608949 ("lib/stackdepot: always do filter_irq_stacks()
in stack_depot_save()").

An architecture may deliver interrupts through entry code that cannot be
placed in .irqentry.text.  in_irqentry_text() then never recognizes the
entry point and the truncation silently stops happening.  The markers are
meant to cover all interrupt entry functions; when they do not, the depot
fills with unfiltered stacks:

  https://lore.kernel.org/all/CACT4Y+aReMGLYua2rCLHgFpS9io5cZC04Q8GLs-uNmrn1ezxYQ@mail.gmail.com/

Add an optional arch_in_event_entry_text() hook, consulted in addition to
the section range checks.  An architecture overrides it by defining a
macro of the same name in <asm/sections.h>, next to the section markers
it tests; the default here is a static inline returning false, which
folds away entirely on every architecture that does not opt in.  This
mirrors the existing arch hook pattern of arch_nmi_enter() in
<linux/hardirq.h>.  The fallback sits next to the hook's only user, so
no generic header gains a new dependency.

Rename in_irqentry_text() to in_event_entry_text() at the same time and
name the hook after it: the ranges it tests are not necessarily irq-only -
on x86 they also cover the exception entry stubs - and what
filter_irq_stacks() asks of them is where a trace entered the kernel.
The helper is file local with a single caller, so the rename stays inside
kernel/stacktrace.c; filter_irq_stacks() keeps its name as it is exported
and used treewide.

No functional change on its own.

The first user is the FRED fix in the follow-up patch.  Both carry the
same Fixes: tag and are Cc'ed to stable so that they are picked up as a
pair.

Fixes: 14619d912b65 ("x86/fred: FRED entry/exit and dispatch code")
Cc: stable@vger.kernel.org # v6.9+
Signed-off-by: Yuanhe Shu <xiangzao@linux.alibaba.com>
Reviewed-by: Bradley Morgan <brads@mainlining.org>
---
 kernel/stacktrace.c | 19 ++++++++++++++++---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/kernel/stacktrace.c b/kernel/stacktrace.c
index afb3c116da91..62b84998b13e 100644
--- a/kernel/stacktrace.c
+++ b/kernel/stacktrace.c
@@ -14,6 +14,7 @@
 #include <linux/kallsyms.h>
 #include <linux/stacktrace.h>
 #include <linux/interrupt.h>
+#include <asm/sections.h>
 
 /**
  * stack_trace_print - Print the entries in the stack trace
@@ -374,12 +375,24 @@ unsigned int stack_trace_save_user(unsigned long *store, unsigned int size)
 
 #endif /* !CONFIG_ARCH_STACKWALK */
 
-static inline bool in_irqentry_text(unsigned long ptr)
+/*
+ * Used to help find where a trace entered the kernel.
+ *
+ * Architectures use this when event entry text cannot be placed in
+ * .irqentry.text alone.  Architectures should define a macro of the
+ * same name in <asm/sections.h>.
+ */
+#ifndef arch_in_event_entry_text
+static inline bool arch_in_event_entry_text(unsigned long addr) { return false; }
+#endif
+
+static inline bool in_event_entry_text(unsigned long ptr)
 {
 	return (ptr >= (unsigned long)&__irqentry_text_start &&
 		ptr < (unsigned long)&__irqentry_text_end) ||
 		(ptr >= (unsigned long)&__softirqentry_text_start &&
-		 ptr < (unsigned long)&__softirqentry_text_end);
+		 ptr < (unsigned long)&__softirqentry_text_end) ||
+		arch_in_event_entry_text(ptr);
 }
 
 /**
@@ -394,7 +407,7 @@ unsigned int filter_irq_stacks(unsigned long *entries, unsigned int nr_entries)
 	unsigned int i;
 
 	for (i = 0; i < nr_entries; i++) {
-		if (in_irqentry_text(entries[i])) {
+		if (in_event_entry_text(entries[i])) {
 			/* Include the irqentry function into the stack. */
 			return i + 1;
 		}
-- 
2.43.7

Re: [PATCH v3 1/2] stacktrace: Provide arch_in_event_entry_text() hook

[Alexander Potapenko]

On Tue, Sep 1, 2026 at 2:40 PM Yuanhe Shu <xiangzao@linux.alibaba.com> wrote:

> The first user is the FRED fix in the follow-up patch.  Both carry the
> same Fixes: tag and are Cc'ed to stable so that they are picked up as a
> pair.
>
> Fixes: 14619d912b65 ("x86/fred: FRED entry/exit and dispatch code")
> Cc: stable@vger.kernel.org # v6.9+
> Signed-off-by: Yuanhe Shu <xiangzao@linux.alibaba.com>
> Reviewed-by: Bradley Morgan <brads@mainlining.org>
Acked-by: Alexander Potapenko <glider@google.com>

[PATCH v3 2/2] x86/fred: Fix stack depot filtering of FRED event stacks

[Yuanhe Shu]

With FRED, events are delivered to asm_fred_entrypoint_user and
asm_fred_entrypoint_kernel in .noinstr.text, not to the IDT stubs, which
are the only code covered by __irqentry_text_start..__irqentry_text_end.
in_event_entry_text() therefore never recognizes the event entry point and
filter_irq_stacks() does not truncate FRED event stacks: every trace
saved from interrupt or exception context by stack depot users such as
KASAN alloc/free tracking or SLUB object tracking combines the event path
with the arbitrarily interrupted context.  The number of unique stacks
grows with the product of both and the depot is exhausted.

Observed on a dual-socket FRED-capable system with KASAN (generic,
inline) and SLUB object tracking enabled, on both sockets roughly 80
minutes after boot, once the depot had reached its maximum of 8192 pools
(128 MiB):

  Stack depot reached limit capacity
  WARNING: CPU: 286 PID: 128614 at lib/stackdepot.c:271 depot_alloc_stack+0x158/0x170

The traces had the expected shape: an interrupt side trace ran through
asm_fred_entrypoint_kernel into the frames of the task it had
interrupted.  New traces are dropped (handle 0) from then on and the
depot never shrinks, so tracking stays dead until reboot.  (Splat from a
6.6 based kernel; filter_irq_stacks() and the FRED entry layout are
unchanged in mainline.)

The entry points cannot be brought inside that range.  x86 has no
.irqentry.text: commit f0178fc01fe4 ("x86/entry: Unbreak
__irqentry_text_start/end magic") dropped it from the linker script and
emits the markers as labels around the sequentially laid out IDT stubs
instead, exactly because the entry rework had moved that code into
.noinstr.text and broken the function graph tracer and
filter_irq_stacks(); __irq_entry has been __invalid_section since.
Those labels live inside entry_64.S and wrap the IDT stubs which
asm/idtentry.h emits into .entry.text, so the linker cannot place
another translation unit between them: only code compiled into
entry_64.S itself can end up inside the range.  Architectures which do
have the section fixed the same symptom locally, e.g.
commit f6794950f0e5 ("arm64: set __exception_irq_entry with __irq_entry
as a default") and commit 45c9f2b856a0 ("s390/entry: Mark IRQ entries
to fix stack depot warnings").

Every FRED event leaves a return address in the FRED entry text: the
return address of the call to fred_entry_from_user/kernel, or a frame of
asm_fred_entry_from_kvm(), which the core entry code uses to forward VMX
interrupts and NMIs acknowledged as part of the VM-Exit; see
commit 0701c9e17bd9 ("x86/kvm/vmx: Move IRQ/NMI dispatch from KVM
into x86 core").  So bracket it with __fred_entry_text_start/end, the
same way the IDT stubs are bracketed, and report that range from
arch_in_event_entry_text().  Verified on that system with the fix
backported: traces from FRED event context now end at
asm_fred_entrypoint_kernel (/sys/kernel/debug/slab/*/alloc_traces) and
the pool count levels off a few minutes after boot instead of climbing
to the limit.

The range covers every FRED entry point, including the ring 3 one which
also serves syscalls, and the hook cannot tell them apart - it only gets
an address.  That does not change any trace: filter_irq_stacks() cuts at
the innermost match, and for anything entered from ring 3 the entry frame
is already the outermost trace entry (the unwinder follows the pt_regs
the entry pushed and stops there because user_mode(regs) is true), so the
trace is returned unchanged.  Only ring 0 events, and the IRQ/NMI the
core forwards through asm_fred_entry_from_kvm(), leave an unrelated
context below the entry frame.  The IDT markers are not IRQ-only either:
they wrap the entire asm/idtentry.h expansion, so the synchronous
exception stubs have always been inside them.  The function graph
tracer uses the same markers and has the same gap; it can be converted
separately.

This is not limited to FRED hardware: KVM_INTEL selects X86_FRED on
x86_64 (commit 28d11e4548b7 ("x86/fred: KVM: VMX: Always use FRED for
IRQs when CONFIG_X86_FRED=y")), so every kernel with Intel KVM support,
built in or as a module, carries the FRED dispatch code, and the
forwarding path above runs it even when the kernel itself uses the IDT.
KVM host stacks therefore take the same untruncated path on non-FRED
systems, albeit from a mostly fixed vcpu_run chain.

Reported-by: Xiang Zheng <xiang.zheng@linux.alibaba.com>
Fixes: 14619d912b65 ("x86/fred: FRED entry/exit and dispatch code")
Cc: stable@vger.kernel.org # v6.9+
Signed-off-by: Yuanhe Shu <xiangzao@linux.alibaba.com>
---
 arch/x86/entry/entry_64_fred.S  | 14 ++++++++++++++
 arch/x86/include/asm/sections.h | 24 ++++++++++++++++++++++++
 2 files changed, 38 insertions(+)

diff --git a/arch/x86/entry/entry_64_fred.S b/arch/x86/entry/entry_64_fred.S
index b98f8945dfff..5a3db902e961 100644
--- a/arch/x86/entry/entry_64_fred.S
+++ b/arch/x86/entry/entry_64_fred.S
@@ -36,6 +36,17 @@
  */
 	.align 4096
 
+/*
+ * Bounds of the FRED event entry text.  Every event delivered by FRED
+ * enters here, including events which the core entry code forwards
+ * through asm_fred_entry_from_kvm().  This is the FRED counterpart of
+ * __irqentry_text_start..__irqentry_text_end and lets
+ * in_event_entry_text() find the event entry point of a stack, see
+ * arch_in_event_entry_text().
+ */
+	.globl __fred_entry_text_start
+__fred_entry_text_start:
+
 SYM_CODE_START_NOALIGN(asm_fred_entrypoint_user)
 	FRED_ENTER
 	call	fred_entry_from_user
@@ -150,3 +161,6 @@ SYM_FUNC_START(asm_fred_entry_from_kvm)
 
 SYM_FUNC_END(asm_fred_entry_from_kvm)
 #endif
+
+	.globl __fred_entry_text_end
+__fred_entry_text_end:
diff --git a/arch/x86/include/asm/sections.h b/arch/x86/include/asm/sections.h
index 30e8ee7006f9..f34170ecc4e4 100644
--- a/arch/x86/include/asm/sections.h
+++ b/arch/x86/include/asm/sections.h
@@ -5,6 +5,30 @@
 #include <asm-generic/sections.h>
 #include <asm/extable.h>
 
+#ifdef CONFIG_X86_FRED
+extern char __fred_entry_text_start[], __fred_entry_text_end[];
+
+#define arch_in_event_entry_text arch_in_event_entry_text
+
+/*
+ * FRED delivers events to entry points in .noinstr.text, which
+ * __irqentry_text_start..__irqentry_text_end does not cover.  See
+ * __fred_entry_text_start in entry_64_fred.S.
+ *
+ * Note that the range includes the ring 3 entry point, which also
+ * delivers syscalls, so it cannot tell interrupt entry and syscall
+ * entry apart.  That is fine for the only consumer,
+ * filter_irq_stacks(): it cuts at the innermost match, and for an
+ * entry from ring 3 the entry frame is already the outermost frame
+ * of the trace, so matching it is a no-op.
+ */
+static inline bool arch_in_event_entry_text(unsigned long addr)
+{
+	return addr >= (unsigned long)__fred_entry_text_start &&
+	       addr < (unsigned long)__fred_entry_text_end;
+}
+#endif
+
 extern char __relocate_kernel_start[], __relocate_kernel_end[];
 extern char __brk_base[], __brk_limit[];
 extern char __end_rodata_aligned[];
-- 
2.43.7

Re: [PATCH v3 2/2] x86/fred: Fix stack depot filtering of FRED event stacks

[Alexander Potapenko]

On Tue, Sep 1, 2026 at 2:40 PM Yuanhe Shu <xiangzao@linux.alibaba.com> wrote:
>

> Reported-by: Xiang Zheng <xiang.zheng@linux.alibaba.com>
> Fixes: 14619d912b65 ("x86/fred: FRED entry/exit and dispatch code")
> Cc: stable@vger.kernel.org # v6.9+
> Signed-off-by: Yuanhe Shu <xiangzao@linux.alibaba.com>
Acked-by: Alexander Potapenko <glider@google.com>