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

[Yuanhe Shu <xiangzao@linux.alibaba.com>]

On Sat, Aug 29, 2026 at 11:42:07AM +0200, Peter Zijlstra wrote:
> I'm not sold on this being a CONFIG symbol, we have far too many of
> those. [...]

Fair enough - v2 uses your pattern and drops the Kconfig symbol.  The
fallback goes next to its only user in kernel/stacktrace.c; putting it in
linux/stacktrace.h would make that header pull in asm/sections.h.  x86
defines the macro next to the markers it tests in asm/sections.h, which
also gets rid of the arch/x86/kernel/stacktrace.c hunk.

> This is all confusing at best. __fred_entry_text covers all entries, it
> cannot distinguish between irqentry and syscall. Why is that not a
> problem?

It can't.  But the only consumer, filter_irq_stacks(), does not use the
range to classify entries - it uses it to find where the event stack
began, and cuts there.  For anything entered from ring 3 the entry frame
is the outermost frame of the trace: the unwinder follows the pt_regs
the entry pushed and stops there because user_mode(regs) is true
(unwind_orc.c, "End-of-stack check for user tasks").  So the cut is a
no-op: the syscall trace is stored whole, same as under the IDT, where
entry_SYSCALL_64 sits outside the range.  An IRQ hitting a task
mid-syscall cuts at the inner kernel entrypoint and drops the interrupted
syscall frames, which is also what the IDT range does today at the
asm_sysvec_* stub.

Only ring-0 events and the IRQ/NMI forwarded through
asm_fred_entry_from_kvm() have an unrelated context below the entry
frame, and those are the ones filling the depot.

The existing markers are not irq-only either: they wrap the whole
asm/idtentry.h expansion, asm_exc_* stubs included, so this range means
the same thing they do.  If you would rather it covered only the ring-0
entry, moving the start marker to asm_fred_entrypoint_kernel (+256)
makes no behavioural difference - I went with the whole block for
symmetry with the IDT side, but have no preference either way.

Thanks,
Yuanhe