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

[Peter Zijlstra <peterz@infradead.org>]

On Mon, Aug 31, 2026 at 04:59:11PM +0800, Yuanhe Shu wrote:
> 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.

I would still argue the function name is incorrect, and the user might
want a comment explaining this.