Re: [DISCUSSION] Three problems behind broken "perf --call-graph dwarf" on AMD: IP and stack dump mismatch, libdw fails on lld's layout, and the unwinder fallback never runs

[Ravi Bangoria <ravi.bangoria@amd.com>]

>>> This should resolve the DWARF unwinding issue with IBS PMUs:
>>>
>>> --- a/arch/x86/events/amd/ibs.c
>>> +++ b/arch/x86/events/amd/ibs.c
>>> @@ -1523,8 +1523,11 @@ static int perf_ibs_handle_irq(struct perf_ibs *perf_ibs, struct pt_regs *iregs)
>>>  			goto out;
>>>  		}
>>>  
>>> -		set_linear_ip(&regs, ibs_data.regs[1]);
>>> -		regs.flags |= PERF_EFLAGS_EXACT;
>>> +		if (event->attr.sample_type & PERF_SAMPLE_IP) {
>>> +			data.ip = ibs_data.regs[1];
>>> +			data.sample_flags |= PERF_SAMPLE_IP;
> 
> We may not set PERF_SAMPLE_IP here, otherwise the kernel address leakage
> check in perf_instruction_pointer() could be bypassed.

Yes. I realized this wouldn't be straightforward, since the privilege
level might change between when the HW captures the sample and when the
NMI is delivered. So, any perf code that depends on user_mode() (e.g.
perf_exclude_event(), _REGS_USER, _REGS_INTR, header->misc, etc.) may
regress with the above change. In addition, guest entry/exit occurring
between sample capture and NMI delivery further complicates the problem.

>> Right, that's what I thought.  And I believe we should do similar on
>> Intel and not update other registers.
> 
> For Intel PEBS, the call-chain would always use the interrupt regs instead
> of the PEBS regs, so there would be no issues for Intel PEBS.
> 
>     /*
>      * We must however always use iregs for the unwinder to stay sane; the
>      * record BP,SP,IP can point into thin air when the record is from a
>      * previous PMI context or an (I)RET happened between the record and
>      * PMI.
>      */
>     perf_sample_save_callchain(data, event, iregs);

This wouldn't take care of _STACK_USER, right?

Thanks,
Ravi