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

[Namhyung Kim <namhyung@kernel.org>]

Hello,

I missed this thread before sending my previous reply.

On Wed, Sep 09, 2026 at 05:36:45PM +0800, Mi, Dapeng wrote:
> 
> On 9/9/2026 4:11 PM, Peter Zijlstra wrote:
> > 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@linux.intel.com> 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.
> 
> Yes, this is about USR_STACK. The CALLCHAIN doesn't suffer this issue since
> perf already returns an IP chain and user space can directly map them to
> the symbols without depending on any register or stack snapshots. :)
> 
> 
> >
> > 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).

That would be great!

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

Cool. It'd be nice to see that happen.

> >
> > This USER_STACK is really the absolute worst possible option. And
> > perhaps refusing PEBS+USER_STACK makes sense.
> 
> If no others insist to implement the precise USER_STACK sampling (what Ian
> suggested), I would give up for sending the drafted precise USER_STACK
> sampling patches. Per my understanding, refusing precise USER_STACK
> sampling what current version does is a cleaner and simpler way.
> Supporting precise USER_STACK sampling inevitably complexes the PEBS/IBS
> handling.

I think precise is for IP and it's not clear if it applies to other REGS
too.  But agree that it'd be simpler to reject.

> 
> BTW, currently perf tools already support the events creation fallback. As
> long as user doesn't explicitly require precise USER_STACK sampling, the
> USER_STACK sampling (--call-graph dwarf) would automatically fallback to
> the PMI-based USER_STACK sampling after the initial precise USER_STACK
> sampling try fails. So it won't really lead to the USER_STACK sampling fails. 

That's true.  perf tools can fallback to auto-reduce the precise level
unless it's requested manually.  If we go on this direction, I think we
should mention this in the man page though.  Probably the condition is
precise_ip + USER_REGS + USER_STACK.

Thanks,
Namhyung