From: Yuanhe Shu <xiangzao@linux.alibaba.com>
To: tglx@kernel.org, mingo@redhat.com, bp@alien8.de,
dave.hansen@linux.intel.com, x86@kernel.org
Cc: hpa@zytor.com, xin@zytor.com, luto@kernel.org,
jpoimboe@kernel.org, peterz@infradead.org, rostedt@goodmis.org,
akpm@linux-foundation.org, rdunlap@infradead.org,
elver@google.com, andreyknvl@gmail.com, glider@google.com,
gor@linux.ibm.com, brads@mainlining.org,
kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org,
Yuanhe Shu <xiangzao@linux.alibaba.com>,
stable@vger.kernel.org
Subject: [PATCH v3 1/2] stacktrace: Provide arch_in_event_entry_text() hook
Date: Tue, 1 Sep 2026 20:40:12 +0800 [thread overview]
Message-ID: <20260901124013.1098560-2-xiangzao@linux.alibaba.com> (raw)
In-Reply-To: <20260901124013.1098560-1-xiangzao@linux.alibaba.com>
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
next prev parent reply other threads:[~2026-09-01 12:40 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-01 12:40 [PATCH v3 0/2] x86/fred: Fix stack depot exhaustion on FRED systems Yuanhe Shu
2026-09-01 12:40 ` Yuanhe Shu [this message]
2026-09-02 13:01 ` [PATCH v3 1/2] stacktrace: Provide arch_in_event_entry_text() hook Alexander Potapenko
2026-09-01 12:40 ` [PATCH v3 2/2] x86/fred: Fix stack depot filtering of FRED event stacks Yuanhe Shu
2026-09-02 13:17 ` Alexander Potapenko
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=20260901124013.1098560-2-xiangzao@linux.alibaba.com \
--to=xiangzao@linux.alibaba.com \
--cc=akpm@linux-foundation.org \
--cc=andreyknvl@gmail.com \
--cc=bp@alien8.de \
--cc=brads@mainlining.org \
--cc=dave.hansen@linux.intel.com \
--cc=elver@google.com \
--cc=glider@google.com \
--cc=gor@linux.ibm.com \
--cc=hpa@zytor.com \
--cc=jpoimboe@kernel.org \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rdunlap@infradead.org \
--cc=rostedt@goodmis.org \
--cc=stable@vger.kernel.org \
--cc=tglx@kernel.org \
--cc=x86@kernel.org \
--cc=xin@zytor.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
all inboxes | Powered by JetHome®