Re: [PATCH 2/2] perf/x86: Disable precise sampling for PERF_SAMPLE_STACK_USER

[Peter Zijlstra]

On Tue, Sep 08, 2026 at 01:56:56PM -0700, Ian Rogers wrote:
> On Tue, Sep 8, 2026 at 8:10 AM Andi Kleen <ak@xxxxxxxxxxxxxxx> wrote:
> >
> > > That's what we already do, no? I have distinct memories of making the
> > > stack unwind use the NMI regs rather then the PEBS regs.
> > >
> > > > In my opinion, it could even make the thing worse. User
> > > > requires to get precise samplings, but perf silently returns imprecise
> > > > records, this would mislead user.
> > >
> > > Mostly just the unwind might be off a little, the rest is accurate. This
> > > has been the case 'forever'. Performance analysis isn't for silly
> > > people, if they can't deal with a little fuzz then perhaps they're in
> > > the wrong business.
> >
> > Is the main problem that the stack doesn't agree? Perhaps there
> > could be a check for regs->rsp == pebs->user rsp (if in user space)
> > to detect problematic samples.
> >
> > The question is how to report it and who should do the checking.
> >
> > It may need new fields in the ABI either to communicate the extra PEBS RSP
> > or a bit to indicate that there might be a mismatch.
> >
> > I guess checking in the kernel and reporting an error might be simpler
> > and maybe cleaner, but it would likely limit more advanced recovery
> > possibilities.
> >
> > Are there other mismatches that break the unwinding? Perhaps the same
> > for RBP?
> 
> For DWARF unwinding any register may be the source of a frame pointer
> (e.g. the OpenSSL library would use R11 rather than RBP).
> 
> There is redundancy on x86 you can sample the PERF_REG_X86_IP register
> in the user register and there is PERF_SAMPLE_IP in the sample event
> itself.
> 
> My understanding is that IBS can only sample IP and so for precise
> samples we can use PERF_SAMPLE_IP as the precise location and the user
> register PERF_REG_X86_IP as the interrupt IP - this would match the
> other register values in the interrupt.
> 
> In DWARF unwinding, we initialize the register state using the sampled
> user registers:

Oh, I had trouble reading yesterday :/ This is about USER_STACK, not
CALLCHAIN.

I think we should try very hard to not use USER_STACK, it is an
abomination. Instead we really should improve CALLCHAIN to be more
useful. There are a pile of patches for kernel based unwinders,
including for .eh_frame (if only I had time to actually go look at
them).

And we should probably look at doing a shadow stack based unwinder as
well.

This USER_STACK is really the absolute worst possible option. And
perhaps refusing PEBS+USER_STACK makes sense.