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

[Andrew Morton]

On Thu, 27 Aug 2026 23:00:21 +0800 Yuanhe Shu <xiangzao@xxxxxxxxxxxxxxxxx> wrote:

> 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@xxxxxxxxxxxxxx/
> 
> 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.

Good call.  I suggest that the same Fixes: be attached to this patch
also, to help ensure that everything lands in the correct place.

I'll assume that both patches will be handled by the x86 maintainers.