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

["Mi, Dapeng" <dapeng1.mi@linux.intel.com>]

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).
>
> 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.

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.

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. 

Thanks.