mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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, kasan-dev@googlegroups.com,
	linux-kernel@vger.kernel.org,
	Yuanhe Shu <xiangzao@linux.alibaba.com>,
	stable@vger.kernel.org
Subject: [PATCH 1/2] stacktrace: Provide arch_in_irqentry_text() hook
Date: Thu, 27 Aug 2026 23:00:21 +0800	[thread overview]
Message-ID: <20260827150022.1618235-2-xiangzao@linux.alibaba.com> (raw)
In-Reply-To: <20260827150022.1618235-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
ends up holding essentially random stacks:

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

Add an optional arch_in_irqentry_text() hook, consulted in addition to
the section range checks, gated on a new ARCH_HAS_IN_IRQENTRY_TEXT
symbol.  Gating keeps the default a static inline returning false, which
folds away entirely on every architecture that does not opt in, instead
of a __weak stub that every architecture would have to call.  This
mirrors the existing ARCH_HAS_* hooks in lib/Kconfig such as
ARCH_HAS_COPY_MC.

No functional change on its own.

The first user is the FRED fix in the follow-up patch, which carries a
Fixes: tag and is Cc'ed to stable; tag this prerequisite for stable too,
so the two are picked up as a pair.

Cc: stable@vger.kernel.org
Signed-off-by: Yuanhe Shu <xiangzao@linux.alibaba.com>
---
 include/linux/stacktrace.h | 16 ++++++++++++++++
 kernel/stacktrace.c        |  3 ++-
 lib/Kconfig                |  3 +++
 3 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/include/linux/stacktrace.h b/include/linux/stacktrace.h
index 525cf60673fe..e933ce86447f 100644
--- a/include/linux/stacktrace.h
+++ b/include/linux/stacktrace.h
@@ -62,6 +62,22 @@ void arch_stack_walk_user(stack_trace_consume_fn consume_entry, void *cookie,
 			  const struct pt_regs *regs);
 #endif /* CONFIG_ARCH_STACKWALK */
 
+/*
+ * Optional arch provided check for additional IRQ entry text, called
+ * in addition to the .irqentry.text and .softirqentry.text range
+ * checks in in_irqentry_text().  Implement this if the architecture
+ * delivers interrupts or exceptions through entry code which cannot
+ * reside in those sections.
+ */
+#ifdef CONFIG_ARCH_HAS_IN_IRQENTRY_TEXT
+bool arch_in_irqentry_text(unsigned long addr);
+#else
+static inline bool arch_in_irqentry_text(unsigned long addr)
+{
+	return false;
+}
+#endif
+
 #ifdef CONFIG_STACKTRACE
 void stack_trace_print(const unsigned long *trace, unsigned int nr_entries,
 		       int spaces);
diff --git a/kernel/stacktrace.c b/kernel/stacktrace.c
index afb3c116da91..9e85ac900889 100644
--- a/kernel/stacktrace.c
+++ b/kernel/stacktrace.c
@@ -379,7 +379,8 @@ static inline bool in_irqentry_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_irqentry_text(ptr);
 }
 
 /**
diff --git a/lib/Kconfig b/lib/Kconfig
index 4e6b34c3346d..45ff30d0a995 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -551,6 +551,9 @@ config ARCH_HAS_COPY_MC
 config ARCH_STACKWALK
        bool
 
+config ARCH_HAS_IN_IRQENTRY_TEXT
+	bool
+
 config STACKDEPOT
 	bool
 	select STACKTRACE
-- 
2.43.5


  reply	other threads:[~2026-08-27 15:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-27 15:00 [PATCH 0/2] x86/fred: Fix stack depot exhaustion on FRED systems Yuanhe Shu
2026-08-27 15:00 ` Yuanhe Shu [this message]
2026-08-27 17:04   ` [PATCH 1/2] stacktrace: Provide arch_in_irqentry_text() hook Bradley Morgan
2026-08-27 23:06   ` Andrew Morton
2026-08-27 15:00 ` [PATCH 2/2] x86/fred: Fix stack depot filtering of FRED event stacks Yuanhe Shu
2026-08-27 21:26   ` H. Peter Anvin
2026-08-29  9:42   ` Peter Zijlstra

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=20260827150022.1618235-2-xiangzao@linux.alibaba.com \
    --to=xiangzao@linux.alibaba.com \
    --cc=akpm@linux-foundation.org \
    --cc=andreyknvl@gmail.com \
    --cc=bp@alien8.de \
    --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®