[PATCH 1/2] perf/x86/intel: Correct pt_regs->flags update for PEBS path

[PATCH 1/2] perf/x86/intel: Correct pt_regs->flags update for PEBS path

[Dapeng Mi]

pt_regs->flags holds the saved CPU FLAGS register. In the PEBS path,
it was incorrectly set to PERF_EFLAGS_EXACT instead of being populated
from the PEBS flags snapshot.

Update pt_regs->flags from PEBS GPR flags if GPRs group is present.

Fixes: c22497f5838c ("perf/x86/intel: Support adaptive PEBS v4")
Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
---
 arch/x86/events/intel/ds.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c
index 8940f0292229..d0bb767a0fef 100644
--- a/arch/x86/events/intel/ds.c
+++ b/arch/x86/events/intel/ds.c
@@ -2432,7 +2432,7 @@ static inline void __setup_pebs_basic_group(struct perf_event *event,
 {
 	/* The ip in basic is EventingIP */
 	set_linear_ip(regs, ip);
-	regs->flags = PERF_EFLAGS_EXACT;
+	regs->flags |= PERF_EFLAGS_EXACT;
 	setup_pebs_time(event, data, tsc);
 
 	if (sample_type & PERF_SAMPLE_WEIGHT_STRUCT)
@@ -2444,9 +2444,17 @@ static inline void __setup_pebs_gpr_group(struct perf_event *event,
 					  struct pebs_gprs *gprs,
 					  u64 sample_type)
 {
+	/*
+	 * Update flags with PEBS data. PERF_EFLAGS_EXACT must be set
+	 * in previous basic group handling.
+	 */
+	regs->flags = gprs->flags | PERF_EFLAGS_EXACT;
+
 	if (event->attr.precise_ip < 2) {
 		set_linear_ip(regs, gprs->ip);
 		regs->flags &= ~PERF_EFLAGS_EXACT;
+	} else if (regs->flags & X86_VM_MASK) {
+		regs->flags ^= (PERF_EFLAGS_VM | X86_VM_MASK);
 	}
 
 	if (sample_type & (PERF_SAMPLE_REGS_INTR | PERF_SAMPLE_REGS_USER))

base-commit: 609d28fba41e977425eff9848e553740bbf155ad
-- 
2.34.1

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

[Dapeng Mi]

PERF_SAMPLE_STACK_USER needs to return the user stack and user registers
to user space when the PMI exits. Since the skid from the PEBS/IBS sample
and PMI delivery, the PEBS/IBS register snapshot (especially IP/SP/BP)
can diverge from the user stack at PMI return. That mismatch breaks DWARF
unwinding.

Precise sampling provides no benefit in this case, so disable PEBS/IBS
precise sampling and allow only PMI-based sampling when
PERF_SAMPLE_STACK_USER is requested.

Reported-by: Gennady Kupava <gennady.kupava@gmail.com>
Closes: https://lore.kernel.org/all/CAPu-DQqF0aF6=GS8Z6KKWeeX_V5LiXeKU_rJQZC+uGg8zuTPNw@mail.gmail.com/
Cc: Ravi Bangoria <ravi.bangoria@amd.com>
Fixes: c5ebcedb566e ("perf: Add ability to attach user stack dump to sample")
Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
---
 arch/x86/events/amd/ibs.c    |  3 +++
 arch/x86/events/core.c       |  3 +++
 arch/x86/events/perf_event.h | 19 +++++++++++++++++++
 3 files changed, 25 insertions(+)

diff --git a/arch/x86/events/amd/ibs.c b/arch/x86/events/amd/ibs.c
index 3531f9c23b8c..c67b659d64e2 100644
--- a/arch/x86/events/amd/ibs.c
+++ b/arch/x86/events/amd/ibs.c
@@ -327,6 +327,9 @@ static int perf_ibs_init(struct perf_event *event)
 	if (has_branch_stack(event))
 		return -EOPNOTSUPP;
 
+	if (!x86_pmu_allow_sample_user_stack(event, true))
+		return -EINVAL;
+
 	/* handle exclude_{user,kernel} in the IRQ handler */
 	if (event->attr.exclude_host || event->attr.exclude_guest ||
 	    event->attr.exclude_idle)
diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
index 8b3ea0adb965..ceb5038d7565 100644
--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -594,6 +594,9 @@ int x86_pmu_hw_config(struct perf_event *event)
 		/* There's no sense in having PEBS for non sampling events: */
 		if (!is_sampling_event(event))
 			return -EINVAL;
+
+		if (!x86_pmu_allow_sample_user_stack(event, false))
+			return -EINVAL;
 	}
 	/*
 	 * check that PEBS LBR correction does not conflict with
diff --git a/arch/x86/events/perf_event.h b/arch/x86/events/perf_event.h
index 71ed5b2acea2..9fbcf2bcef51 100644
--- a/arch/x86/events/perf_event.h
+++ b/arch/x86/events/perf_event.h
@@ -1274,6 +1274,25 @@ static inline bool is_counter_pair(struct hw_perf_event *hwc)
 	return hwc->flags & PERF_X86_EVENT_PAIR;
 }
 
+static inline bool
+x86_pmu_allow_sample_user_stack(struct perf_event *event, bool ibs)
+{
+	if (!(event->attr.sample_type & PERF_SAMPLE_STACK_USER))
+		return true;
+
+	/*
+	 * PERF_SAMPLE_STACK_USER needs to return the user stack and
+	 * user registers to user space when the PMI exits. Since the skid
+	 * from the PEBS/IBS sample and PMI delivery, the PEBS/IBS register
+	 * snapshot (especially IP/SP/BP) can diverge from the user stack
+	 * at PMI return. That mismatch breaks DWARF unwinding.
+	 *
+	 * Therefore, disable precise sampling for PERF_SAMPLE_STACK_USER
+	 * and permit only PMI-based sampling for this case.
+	 */
+	return !(event->attr.precise_ip || ibs);
+}
+
 static inline void __x86_pmu_enable_event(struct hw_perf_event *hwc,
 					  u64 enable_mask)
 {
-- 
2.34.1

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

[Peter Zijlstra]

On Tue, Sep 08, 2026 at 03:51:02PM +0800, Dapeng Mi wrote:
> PERF_SAMPLE_STACK_USER needs to return the user stack and user registers
> to user space when the PMI exits. Since the skid from the PEBS/IBS sample
> and PMI delivery, the PEBS/IBS register snapshot (especially IP/SP/BP)
> can diverge from the user stack at PMI return. That mismatch breaks DWARF
> unwinding.
> 
> Precise sampling provides no benefit in this case, so disable PEBS/IBS
> precise sampling and allow only PMI-based sampling when
> PERF_SAMPLE_STACK_USER is requested.
> 
> Reported-by: Gennady Kupava <gennady.kupava@gmail.com>
> Closes: https://lore.kernel.org/all/CAPu-DQqF0aF6=GS8Z6KKWeeX_V5LiXeKU_rJQZC+uGg8zuTPNw@mail.gmail.com/
> Cc: Ravi Bangoria <ravi.bangoria@amd.com>
> Fixes: c5ebcedb566e ("perf: Add ability to attach user stack dump to sample")
> Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>

This breaks long standing existing behaviour.

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

[Mi, Dapeng]

The patch is only validated on Intel platforms. @Ravi may help to validate
on AMD platforms. Thanks.

On 9/8/2026 3:51 PM, Dapeng Mi wrote:
> PERF_SAMPLE_STACK_USER needs to return the user stack and user registers
> to user space when the PMI exits. Since the skid from the PEBS/IBS sample
> and PMI delivery, the PEBS/IBS register snapshot (especially IP/SP/BP)
> can diverge from the user stack at PMI return. That mismatch breaks DWARF
> unwinding.
>
> Precise sampling provides no benefit in this case, so disable PEBS/IBS
> precise sampling and allow only PMI-based sampling when
> PERF_SAMPLE_STACK_USER is requested.
>
> Reported-by: Gennady Kupava <gennady.kupava@gmail.com>
> Closes: https://lore.kernel.org/all/CAPu-DQqF0aF6=GS8Z6KKWeeX_V5LiXeKU_rJQZC+uGg8zuTPNw@mail.gmail.com/
> Cc: Ravi Bangoria <ravi.bangoria@amd.com>
> Fixes: c5ebcedb566e ("perf: Add ability to attach user stack dump to sample")
> Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
> ---
>  arch/x86/events/amd/ibs.c    |  3 +++
>  arch/x86/events/core.c       |  3 +++
>  arch/x86/events/perf_event.h | 19 +++++++++++++++++++
>  3 files changed, 25 insertions(+)
>
> diff --git a/arch/x86/events/amd/ibs.c b/arch/x86/events/amd/ibs.c
> index 3531f9c23b8c..c67b659d64e2 100644
> --- a/arch/x86/events/amd/ibs.c
> +++ b/arch/x86/events/amd/ibs.c
> @@ -327,6 +327,9 @@ static int perf_ibs_init(struct perf_event *event)
>  	if (has_branch_stack(event))
>  		return -EOPNOTSUPP;
>  
> +	if (!x86_pmu_allow_sample_user_stack(event, true))
> +		return -EINVAL;
> +
>  	/* handle exclude_{user,kernel} in the IRQ handler */
>  	if (event->attr.exclude_host || event->attr.exclude_guest ||
>  	    event->attr.exclude_idle)
> diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
> index 8b3ea0adb965..ceb5038d7565 100644
> --- a/arch/x86/events/core.c
> +++ b/arch/x86/events/core.c
> @@ -594,6 +594,9 @@ int x86_pmu_hw_config(struct perf_event *event)
>  		/* There's no sense in having PEBS for non sampling events: */
>  		if (!is_sampling_event(event))
>  			return -EINVAL;
> +
> +		if (!x86_pmu_allow_sample_user_stack(event, false))
> +			return -EINVAL;
>  	}
>  	/*
>  	 * check that PEBS LBR correction does not conflict with
> diff --git a/arch/x86/events/perf_event.h b/arch/x86/events/perf_event.h
> index 71ed5b2acea2..9fbcf2bcef51 100644
> --- a/arch/x86/events/perf_event.h
> +++ b/arch/x86/events/perf_event.h
> @@ -1274,6 +1274,25 @@ static inline bool is_counter_pair(struct hw_perf_event *hwc)
>  	return hwc->flags & PERF_X86_EVENT_PAIR;
>  }
>  
> +static inline bool
> +x86_pmu_allow_sample_user_stack(struct perf_event *event, bool ibs)
> +{
> +	if (!(event->attr.sample_type & PERF_SAMPLE_STACK_USER))
> +		return true;
> +
> +	/*
> +	 * PERF_SAMPLE_STACK_USER needs to return the user stack and
> +	 * user registers to user space when the PMI exits. Since the skid
> +	 * from the PEBS/IBS sample and PMI delivery, the PEBS/IBS register
> +	 * snapshot (especially IP/SP/BP) can diverge from the user stack
> +	 * at PMI return. That mismatch breaks DWARF unwinding.
> +	 *
> +	 * Therefore, disable precise sampling for PERF_SAMPLE_STACK_USER
> +	 * and permit only PMI-based sampling for this case.
> +	 */
> +	return !(event->attr.precise_ip || ibs);
> +}
> +
>  static inline void __x86_pmu_enable_event(struct hw_perf_event *hwc,
>  					  u64 enable_mask)
>  {

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

[Mi, Dapeng]

On 9/8/2026 4:49 PM, Peter Zijlstra wrote:
> On Tue, Sep 08, 2026 at 03:51:02PM +0800, Dapeng Mi wrote:
>> PERF_SAMPLE_STACK_USER needs to return the user stack and user registers
>> to user space when the PMI exits. Since the skid from the PEBS/IBS sample
>> and PMI delivery, the PEBS/IBS register snapshot (especially IP/SP/BP)
>> can diverge from the user stack at PMI return. That mismatch breaks DWARF
>> unwinding.
>>
>> Precise sampling provides no benefit in this case, so disable PEBS/IBS
>> precise sampling and allow only PMI-based sampling when
>> PERF_SAMPLE_STACK_USER is requested.
>>
>> Reported-by: Gennady Kupava <gennady.kupava@gmail.com>
>> Closes: https://lore.kernel.org/all/CAPu-DQqF0aF6=GS8Z6KKWeeX_V5LiXeKU_rJQZC+uGg8zuTPNw@mail.gmail.com/
>> Cc: Ravi Bangoria <ravi.bangoria@amd.com>
>> Fixes: c5ebcedb566e ("perf: Add ability to attach user stack dump to sample")
>> Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
> This breaks long standing existing behaviour.

Yeah, but it seems there is no better way to fix this issue.

An alternative way to fix this issue is still to return the PMI context register state rather than the PEBS precise registers for user stack sampling, but this actually falls back the imprecise PMI-based sampling. 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. 

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

[Peter Zijlstra]

On Tue, Sep 08, 2026 at 04:56:22PM +0800, Mi, Dapeng wrote:
> 
> On 9/8/2026 4:49 PM, Peter Zijlstra wrote:
> > On Tue, Sep 08, 2026 at 03:51:02PM +0800, Dapeng Mi wrote:
> >> PERF_SAMPLE_STACK_USER needs to return the user stack and user registers
> >> to user space when the PMI exits. Since the skid from the PEBS/IBS sample
> >> and PMI delivery, the PEBS/IBS register snapshot (especially IP/SP/BP)
> >> can diverge from the user stack at PMI return. That mismatch breaks DWARF
> >> unwinding.
> >>
> >> Precise sampling provides no benefit in this case, so disable PEBS/IBS
> >> precise sampling and allow only PMI-based sampling when
> >> PERF_SAMPLE_STACK_USER is requested.
> >>
> >> Reported-by: Gennady Kupava <gennady.kupava@gmail.com>
> >> Closes: https://lore.kernel.org/all/CAPu-DQqF0aF6=GS8Z6KKWeeX_V5LiXeKU_rJQZC+uGg8zuTPNw@mail.gmail.com/
> >> Cc: Ravi Bangoria <ravi.bangoria@amd.com>
> >> Fixes: c5ebcedb566e ("perf: Add ability to attach user stack dump to sample")
> >> Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
> > This breaks long standing existing behaviour.
> 
> Yeah, but it seems there is no better way to fix this issue.

Breaking things that worked before isn't fixing.. people get upset.

> An alternative way to fix this issue is still to return the PMI
> context register state rather than the PEBS precise registers for user
> stack sampling, but this actually falls back the imprecise PMI-based
> sampling. 

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.

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

[Andi Kleen]

> 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?

-Andi

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

[Ian Rogers]

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:
https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/util/unwind-libdw.c?h=perf-tools-next#n270
and on x86 we sample all registers for DWARF unwinding:
https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/arch/x86/include/perf_regs.h?h=perf-tools-next#n20
https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/util/perf-regs-arch/perf_regs_x86.c?h=perf-tools-next#n238

Having PERF_SAMPLE_IP be precise and the user registers from the
interrupt I believe works for AMD IBS and ARM SPE, but for Intel PEBS
there is the ability to use the PEBS register samples for other
non-redundant registers. In the x86 driver could we disable PEBS
sampling for these registers when doing user stack sampling, so that
the sampled user registers match the stack sample? We can keep the
PERF_SAMPLE_IP precise, and make all the registers precise when there
is no stack sampling.

Thanks,
Ian

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

[Mi, Dapeng]

On 9/9/2026 4:56 AM, 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:
> https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/util/unwind-libdw.c?h=perf-tools-next#n270
> and on x86 we sample all registers for DWARF unwinding:
> https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/arch/x86/include/perf_regs.h?h=perf-tools-next#n20
> https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/util/perf-regs-arch/perf_regs_x86.c?h=perf-tools-next#n238
>
> Having PERF_SAMPLE_IP be precise and the user registers from the
> interrupt I believe works for AMD IBS and ARM SPE, but for Intel PEBS
> there is the ability to use the PEBS register samples for other
> non-redundant registers. In the x86 driver could we disable PEBS
> sampling for these registers when doing user stack sampling, so that
> the sampled user registers match the stack sample? We can keep the
> PERF_SAMPLE_IP precise, and make all the registers precise when there
> is no stack sampling.

That sounds the best way to fix this issue by decoupling PERF_SAMPLE_IP
with PERF_REG_X86_IP. Then we can keep the precise SAMPLE_IP and the PMI
context user register snapshot simultaneously.

I would post v2 patch with this fix. Thanks.


>
> Thanks,
> Ian

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

[Mi, Dapeng]

On 9/8/2026 6:19 PM, Peter Zijlstra wrote:
> On Tue, Sep 08, 2026 at 04:56:22PM +0800, Mi, Dapeng wrote:
>> On 9/8/2026 4:49 PM, Peter Zijlstra wrote:
>>> On Tue, Sep 08, 2026 at 03:51:02PM +0800, Dapeng Mi wrote:
>>>> PERF_SAMPLE_STACK_USER needs to return the user stack and user registers
>>>> to user space when the PMI exits. Since the skid from the PEBS/IBS sample
>>>> and PMI delivery, the PEBS/IBS register snapshot (especially IP/SP/BP)
>>>> can diverge from the user stack at PMI return. That mismatch breaks DWARF
>>>> unwinding.
>>>>
>>>> Precise sampling provides no benefit in this case, so disable PEBS/IBS
>>>> precise sampling and allow only PMI-based sampling when
>>>> PERF_SAMPLE_STACK_USER is requested.
>>>>
>>>> Reported-by: Gennady Kupava <gennady.kupava@gmail.com>
>>>> Closes: https://lore.kernel.org/all/CAPu-DQqF0aF6=GS8Z6KKWeeX_V5LiXeKU_rJQZC+uGg8zuTPNw@mail.gmail.com/
>>>> Cc: Ravi Bangoria <ravi.bangoria@amd.com>
>>>> Fixes: c5ebcedb566e ("perf: Add ability to attach user stack dump to sample")
>>>> Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
>>> This breaks long standing existing behaviour.
>> Yeah, but it seems there is no better way to fix this issue.
> Breaking things that worked before isn't fixing.. people get upset.
>
>> An alternative way to fix this issue is still to return the PMI
>> context register state rather than the PEBS precise registers for user
>> stack sampling, but this actually falls back the imprecise PMI-based
>> sampling. 
> 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.

Unfortunately it's not. :(

Currently pt_regs->ip would be unconditionally overwritten by PEBS/IBS
snapshotted IP register value, and then the pt_regs->ip is used to
generated the SAMPLE_IP.

    if (filtered_sample_type & PERF_SAMPLE_IP) {
        data->ip = perf_instruction_pointer(event, regs);
        data->sample_flags |= PERF_SAMPLE_IP;
    }

As Ian suggested, the better way to fix this issue could be to decouple
PERF_SAMPLE_IP and PERF_REG_X86_IP. PERF_SAMPLE_IP still stores the precise
IP from PEBS/IBS, but the whole user register snapshot keeps the PMI
context registers. DWARF depends on the user register snapshot to unwind
the call chain instead of PERF_SAMPLE_IP.

I would follow this way and send V2 patches. 

Thanks.


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

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

[Ravi Bangoria]

>> Having PERF_SAMPLE_IP be precise and the user registers from the
>> interrupt I believe works for AMD IBS and ARM SPE, but for Intel PEBS
>> there is the ability to use the PEBS register samples for other
>> non-redundant registers. In the x86 driver could we disable PEBS
>> sampling for these registers when doing user stack sampling, so that
>> the sampled user registers match the stack sample? We can keep the
>> PERF_SAMPLE_IP precise, and make all the registers precise when there
>> is no stack sampling.
> 
> That sounds the best way to fix this issue by decoupling PERF_SAMPLE_IP
> with PERF_REG_X86_IP. Then we can keep the precise SAMPLE_IP and the PMI
> context user register snapshot simultaneously.

With this, PERF_SAMPLE_IP and PERF_REG_X86_IP might be from different
privileges. So, any perf code that depends on user_mode(regs) (e.g.
perf_exclude_event(), _REGS_USER, _REGS_INTR, header->misc, etc.) also
needs to be inspected/modified accordingly.

Thanks,
Ravi

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

[Mi, Dapeng]

On 9/9/2026 9:28 AM, Ravi Bangoria wrote:
>>> Having PERF_SAMPLE_IP be precise and the user registers from the
>>> interrupt I believe works for AMD IBS and ARM SPE, but for Intel PEBS
>>> there is the ability to use the PEBS register samples for other
>>> non-redundant registers. In the x86 driver could we disable PEBS
>>> sampling for these registers when doing user stack sampling, so that
>>> the sampled user registers match the stack sample? We can keep the
>>> PERF_SAMPLE_IP precise, and make all the registers precise when there
>>> is no stack sampling.
>> That sounds the best way to fix this issue by decoupling PERF_SAMPLE_IP
>> with PERF_REG_X86_IP. Then we can keep the precise SAMPLE_IP and the PMI
>> context user register snapshot simultaneously.
> With this, PERF_SAMPLE_IP and PERF_REG_X86_IP might be from different
> privileges. So, any perf code that depends on user_mode(regs) (e.g.
> perf_exclude_event(), _REGS_USER, _REGS_INTR, header->misc, etc.) also
> needs to be inspected/modified accordingly.

Yeah, this introduces the inconsistency between PERF_SAMPLE_IP and the
pt_regs, but I suppose it should be fine. I didn't look at the details yet,
but all places which call user_mode(regs) should not be impacted in theory.
As long as we ensure the PERF_SAMPLE_IP doesn't leak security information
like kernel address, I suppose it should be fine. 

Thanks.


>
> Thanks,
> Ravi

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

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.

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

[Mi, Dapeng]

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.

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

[Namhyung Kim]

Hello,

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:
> https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/util/unwind-libdw.c?h=perf-tools-next#n270
> and on x86 we sample all registers for DWARF unwinding:
> https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/arch/x86/include/perf_regs.h?h=perf-tools-next#n20
> https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/util/perf-regs-arch/perf_regs_x86.c?h=perf-tools-next#n238
> 
> Having PERF_SAMPLE_IP be precise and the user registers from the
> interrupt I believe works for AMD IBS and ARM SPE, but for Intel PEBS
> there is the ability to use the PEBS register samples for other
> non-redundant registers. In the x86 driver could we disable PEBS
> sampling for these registers when doing user stack sampling, so that
> the sampled user registers match the stack sample? We can keep the
> PERF_SAMPLE_IP precise, and make all the registers precise when there
> is no stack sampling.

+1.

I think it's better to keep PERF_SAMPLE_IP precise as requested and pick
appropriate registers based on PERF_SAMPLE_USER_STACK.

Thanks,
Namhyung

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

[Namhyung Kim]

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

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

[Mi, Dapeng]

On 9/10/2026 3:30 AM, Namhyung Kim wrote:
> 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.

Good idea. I would add an independent perf-tools patch to mention this once
we decide to go on this direction. Thanks.


>
> Thanks,
> Namhyung

[tip: perf/urgent] perf/x86/intel: Correct pt_regs->flags update for PEBS path

[tip-bot2 for Dapeng Mi]

The following commit has been merged into the perf/urgent branch of tip:

Commit-ID:     88aa1223bfffb1a0a98c639e9e1f71058f0d9178
Gitweb:        https://git.kernel.org/tip/88aa1223bfffb1a0a98c639e9e1f71058f0d9178
Author:        Dapeng Mi <dapeng1.mi@linux.intel.com>
AuthorDate:    Tue, 08 Sep 2026 15:51:01 +08:00
Committer:     Peter Zijlstra <peterz@infradead.org>
CommitterDate: Thu, 10 Sep 2026 10:22:50 +02:00

perf/x86/intel: Correct pt_regs->flags update for PEBS path

pt_regs->flags holds the saved CPU FLAGS register. In the PEBS path,
it was incorrectly set to PERF_EFLAGS_EXACT instead of being populated
from the PEBS flags snapshot.

Update pt_regs->flags from PEBS GPR flags if GPRs group is present.

Fixes: c22497f5838c ("perf/x86/intel: Support adaptive PEBS v4")
Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patch.msgid.link/20260908075102.540715-1-dapeng1.mi@linux.intel.com
---
 arch/x86/events/intel/ds.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c
index 8940f02..d0bb767 100644
--- a/arch/x86/events/intel/ds.c
+++ b/arch/x86/events/intel/ds.c
@@ -2432,7 +2432,7 @@ static inline void __setup_pebs_basic_group(struct perf_event *event,
 {
 	/* The ip in basic is EventingIP */
 	set_linear_ip(regs, ip);
-	regs->flags = PERF_EFLAGS_EXACT;
+	regs->flags |= PERF_EFLAGS_EXACT;
 	setup_pebs_time(event, data, tsc);
 
 	if (sample_type & PERF_SAMPLE_WEIGHT_STRUCT)
@@ -2444,9 +2444,17 @@ static inline void __setup_pebs_gpr_group(struct perf_event *event,
 					  struct pebs_gprs *gprs,
 					  u64 sample_type)
 {
+	/*
+	 * Update flags with PEBS data. PERF_EFLAGS_EXACT must be set
+	 * in previous basic group handling.
+	 */
+	regs->flags = gprs->flags | PERF_EFLAGS_EXACT;
+
 	if (event->attr.precise_ip < 2) {
 		set_linear_ip(regs, gprs->ip);
 		regs->flags &= ~PERF_EFLAGS_EXACT;
+	} else if (regs->flags & X86_VM_MASK) {
+		regs->flags ^= (PERF_EFLAGS_VM | X86_VM_MASK);
 	}
 
 	if (sample_type & (PERF_SAMPLE_REGS_INTR | PERF_SAMPLE_REGS_USER))