Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On Tue, Jul 11, 2017 at 8:32 AM, Kyle Huey wrote: > On Tue, Jul 11, 2017 at 2:03 AM, Ingo Molnar wrote: >> >> * Kyle Huey wrote: >> >>> On Wed, Jul 5, 2017 at 10:07 PM, Robert O'Callahan >>> wrote: >>> > On Tue, Jul

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On Tue, Jul 11, 2017 at 8:32 AM, Kyle Huey wrote: > On Tue, Jul 11, 2017 at 2:03 AM, Ingo Molnar wrote: >> >> * Kyle Huey wrote: >> >>> On Wed, Jul 5, 2017 at 10:07 PM, Robert O'Callahan >>> wrote: >>> > On Tue, Jul 4, 2017 at 3:21 AM, Mark Rutland wrote: >>> >> Should any of those be moved

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

* Jin, Yao wrote: > Could we provide 2 options in user space when enabling the event sampling? > > One option is for the use case like rr debugger which only cares the PMI > interrupt but doesn't care the skid. The skid samples doesn't need to be > dropped. Since

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

* Jin, Yao wrote: > Could we provide 2 options in user space when enabling the event sampling? > > One option is for the use case like rr debugger which only cares the PMI > interrupt but doesn't care the skid. The skid samples doesn't need to be > dropped. Since it's an information leak,

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On Tue, Jul 11, 2017 at 2:03 AM, Ingo Molnar wrote: > > * Kyle Huey wrote: > >> On Wed, Jul 5, 2017 at 10:07 PM, Robert O'Callahan >> wrote: >> > On Tue, Jul 4, 2017 at 3:21 AM, Mark Rutland wrote: >> >> Should

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On Tue, Jul 11, 2017 at 2:03 AM, Ingo Molnar wrote: > > * Kyle Huey wrote: > >> On Wed, Jul 5, 2017 at 10:07 PM, Robert O'Callahan >> wrote: >> > On Tue, Jul 4, 2017 at 3:21 AM, Mark Rutland wrote: >> >> Should any of those be moved into the "should be dropped" pile? >> > >> > Why not be

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On Tue, Jul 11, 2017 at 11:03:58AM +0200, Ingo Molnar wrote: > > * Kyle Huey wrote: > > > On Wed, Jul 5, 2017 at 10:07 PM, Robert O'Callahan > > wrote: > > > On Tue, Jul 4, 2017 at 3:21 AM, Mark Rutland wrote: > > >> Should any

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On Tue, Jul 11, 2017 at 11:03:58AM +0200, Ingo Molnar wrote: > > * Kyle Huey wrote: > > > On Wed, Jul 5, 2017 at 10:07 PM, Robert O'Callahan > > wrote: > > > On Tue, Jul 4, 2017 at 3:21 AM, Mark Rutland wrote: > > >> Should any of those be moved into the "should be dropped" pile? > > > > > >

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On 7/11/2017 5:03 PM, Ingo Molnar wrote: * Kyle Huey wrote: On Wed, Jul 5, 2017 at 10:07 PM, Robert O'Callahan wrote: On Tue, Jul 4, 2017 at 3:21 AM, Mark Rutland wrote: Should any of those be moved into the "should be

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On 7/11/2017 5:03 PM, Ingo Molnar wrote: * Kyle Huey wrote: On Wed, Jul 5, 2017 at 10:07 PM, Robert O'Callahan wrote: On Tue, Jul 4, 2017 at 3:21 AM, Mark Rutland wrote: Should any of those be moved into the "should be dropped" pile? Why not be conservative and clear every sample

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

* Kyle Huey wrote: > On Wed, Jul 5, 2017 at 10:07 PM, Robert O'Callahan > wrote: > > On Tue, Jul 4, 2017 at 3:21 AM, Mark Rutland wrote: > >> Should any of those be moved into the "should be dropped" pile? > > > > Why not be

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

* Kyle Huey wrote: > On Wed, Jul 5, 2017 at 10:07 PM, Robert O'Callahan > wrote: > > On Tue, Jul 4, 2017 at 3:21 AM, Mark Rutland wrote: > >> Should any of those be moved into the "should be dropped" pile? > > > > Why not be conservative and clear every sample you're not sure about? > > > >

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On Wed, Jul 5, 2017 at 10:07 PM, Robert O'Callahan wrote: > On Tue, Jul 4, 2017 at 3:21 AM, Mark Rutland wrote: >> Should any of those be moved into the "should be dropped" pile? > > Why not be conservative and clear every sample you're not sure about?

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On Wed, Jul 5, 2017 at 10:07 PM, Robert O'Callahan wrote: > On Tue, Jul 4, 2017 at 3:21 AM, Mark Rutland wrote: >> Should any of those be moved into the "should be dropped" pile? > > Why not be conservative and clear every sample you're not sure about? > > We'd appreciate a fix sooner rather

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On Tue, Jul 4, 2017 at 3:21 AM, Mark Rutland wrote: > Should any of those be moved into the "should be dropped" pile? Why not be conservative and clear every sample you're not sure about? We'd appreciate a fix sooner rather than later here, since rr is currently broken on

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On Tue, Jul 4, 2017 at 3:21 AM, Mark Rutland wrote: > Should any of those be moved into the "should be dropped" pile? Why not be conservative and clear every sample you're not sure about? We'd appreciate a fix sooner rather than later here, since rr is currently broken on every stable Linux

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On Tue, Jul 04, 2017 at 10:33:45AM +0100, Mark Rutland wrote: > On Tue, Jul 04, 2017 at 11:03:13AM +0200, Peter Zijlstra wrote: > > Faking data gets a wee bit tricky in how much data we need to clear > > through, its not only IP, pretty much everything we get from the > > interrupt context, like

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On Tue, Jul 04, 2017 at 10:33:45AM +0100, Mark Rutland wrote: > On Tue, Jul 04, 2017 at 11:03:13AM +0200, Peter Zijlstra wrote: > > Faking data gets a wee bit tricky in how much data we need to clear > > through, its not only IP, pretty much everything we get from the > > interrupt context, like

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

* Peter Zijlstra wrote: > On Thu, Jun 29, 2017 at 10:12:33AM +0200, Ingo Molnar wrote: > > > > * Mark Rutland wrote: > > > > > It still seems wrong to make up data, though. > > > > So what we have here is a hardware quirk: we asked for user-space

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

* Peter Zijlstra wrote: > On Thu, Jun 29, 2017 at 10:12:33AM +0200, Ingo Molnar wrote: > > > > * Mark Rutland wrote: > > > > > It still seems wrong to make up data, though. > > > > So what we have here is a hardware quirk: we asked for user-space samples, > > but > > didn't get them and

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On Tue, Jul 04, 2017 at 10:33:45AM +0100, Mark Rutland wrote: > > That said, with a per-cpu event the TID sample value is indeed subject > > to skid like you describe. > > For per-cpu events, does that matter? Those don't have TID filters in > the first place, no? eBPF can do all sorts I

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On Tue, Jul 04, 2017 at 10:33:45AM +0100, Mark Rutland wrote: > > That said, with a per-cpu event the TID sample value is indeed subject > > to skid like you describe. > > For per-cpu events, does that matter? Those don't have TID filters in > the first place, no? eBPF can do all sorts I

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On Tue, Jul 04, 2017 at 11:03:13AM +0200, Peter Zijlstra wrote: > On Wed, Jun 28, 2017 at 03:55:07PM -0700, Kyle Huey wrote: > > > > Having thought about this some more, I think Vince does make a good > > > point that throwing away samples is liable to break stuff, e.g. that > > > which only

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On Tue, Jul 04, 2017 at 11:03:13AM +0200, Peter Zijlstra wrote: > On Wed, Jun 28, 2017 at 03:55:07PM -0700, Kyle Huey wrote: > > > > Having thought about this some more, I think Vince does make a good > > > point that throwing away samples is liable to break stuff, e.g. that > > > which only

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On Thu, Jun 29, 2017 at 10:12:33AM +0200, Ingo Molnar wrote: > > * Mark Rutland wrote: > > > It still seems wrong to make up data, though. > > So what we have here is a hardware quirk: we asked for user-space samples, > but > didn't get them and we cannot expose the

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On Thu, Jun 29, 2017 at 10:12:33AM +0200, Ingo Molnar wrote: > > * Mark Rutland wrote: > > > It still seems wrong to make up data, though. > > So what we have here is a hardware quirk: we asked for user-space samples, > but > didn't get them and we cannot expose the kernel-internal address.

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On Wed, Jun 28, 2017 at 03:55:07PM -0700, Kyle Huey wrote: > > Having thought about this some more, I think Vince does make a good > > point that throwing away samples is liable to break stuff, e.g. that > > which only relies on (non-sensitive) samples. > > > > It still seems wrong to make up

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On Wed, Jun 28, 2017 at 03:55:07PM -0700, Kyle Huey wrote: > > Having thought about this some more, I think Vince does make a good > > point that throwing away samples is liable to break stuff, e.g. that > > which only relies on (non-sensitive) samples. > > > > It still seems wrong to make up

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On Wed, Jun 28, 2017 at 3:55 PM, Kyle Huey wrote: > On Wed, Jun 28, 2017 at 10:49 AM, Mark Rutland wrote: >> On Wed, Jun 28, 2017 at 09:48:27AM -0700, Kyle Huey wrote: >>> On Wed, Jun 28, 2017 at 3:56 AM, Mark Rutland wrote: >>> >

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On Wed, Jun 28, 2017 at 3:55 PM, Kyle Huey wrote: > On Wed, Jun 28, 2017 at 10:49 AM, Mark Rutland wrote: >> On Wed, Jun 28, 2017 at 09:48:27AM -0700, Kyle Huey wrote: >>> On Wed, Jun 28, 2017 at 3:56 AM, Mark Rutland wrote: >>> > @@ -6101,6 +6116,12 @@ void perf_prepare_sample(struct

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On 29.06.2017 11:13, Alexey Budankov wrote: > Hi Folks, > > On 28.06.2017 16:07, Mark Rutland wrote: >> On Wed, Jun 28, 2017 at 08:40:30AM -0400, Vince Weaver wrote: >>> On Wed, 28 Jun 2017, Mark Rutland wrote: >>> On Wed, Jun 28, 2017 at 11:12:48AM +0100, Mark Rutland wrote: >>>

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On 29.06.2017 11:13, Alexey Budankov wrote: > Hi Folks, > > On 28.06.2017 16:07, Mark Rutland wrote: >> On Wed, Jun 28, 2017 at 08:40:30AM -0400, Vince Weaver wrote: >>> On Wed, 28 Jun 2017, Mark Rutland wrote: >>> On Wed, Jun 28, 2017 at 11:12:48AM +0100, Mark Rutland wrote: >>>

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

Hi Folks, On 28.06.2017 16:07, Mark Rutland wrote: > On Wed, Jun 28, 2017 at 08:40:30AM -0400, Vince Weaver wrote: >> On Wed, 28 Jun 2017, Mark Rutland wrote: >> >>> On Wed, Jun 28, 2017 at 11:12:48AM +0100, Mark Rutland wrote: >> >>> Instead of bailing out early in perf_event_overflow, we can

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

Hi Folks, On 28.06.2017 16:07, Mark Rutland wrote: > On Wed, Jun 28, 2017 at 08:40:30AM -0400, Vince Weaver wrote: >> On Wed, 28 Jun 2017, Mark Rutland wrote: >> >>> On Wed, Jun 28, 2017 at 11:12:48AM +0100, Mark Rutland wrote: >> >>> Instead of bailing out early in perf_event_overflow, we can

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

* Mark Rutland wrote: > It still seems wrong to make up data, though. So what we have here is a hardware quirk: we asked for user-space samples, but didn't get them and we cannot expose the kernel-internal address. The question is, how do we handle the hardware quirk.

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

* Mark Rutland wrote: > It still seems wrong to make up data, though. So what we have here is a hardware quirk: we asked for user-space samples, but didn't get them and we cannot expose the kernel-internal address. The question is, how do we handle the hardware quirk. Since we cannot fix the

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On 6/29/2017 6:55 AM, Kyle Huey wrote: On Wed, Jun 28, 2017 at 10:49 AM, Mark Rutland wrote: On Wed, Jun 28, 2017 at 09:48:27AM -0700, Kyle Huey wrote: On Wed, Jun 28, 2017 at 3:56 AM, Mark Rutland wrote: @@ -6101,6 +6116,12 @@ void

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On 6/29/2017 6:55 AM, Kyle Huey wrote: On Wed, Jun 28, 2017 at 10:49 AM, Mark Rutland wrote: On Wed, Jun 28, 2017 at 09:48:27AM -0700, Kyle Huey wrote: On Wed, Jun 28, 2017 at 3:56 AM, Mark Rutland wrote: @@ -6101,6 +6116,12 @@ void perf_prepare_sample(struct perf_event_header *header,

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On Wed, Jun 28, 2017 at 10:49 AM, Mark Rutland wrote: > On Wed, Jun 28, 2017 at 09:48:27AM -0700, Kyle Huey wrote: >> On Wed, Jun 28, 2017 at 3:56 AM, Mark Rutland wrote: >> > @@ -6101,6 +6116,12 @@ void perf_prepare_sample(struct perf_event_header >>

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On Wed, Jun 28, 2017 at 10:49 AM, Mark Rutland wrote: > On Wed, Jun 28, 2017 at 09:48:27AM -0700, Kyle Huey wrote: >> On Wed, Jun 28, 2017 at 3:56 AM, Mark Rutland wrote: >> > @@ -6101,6 +6116,12 @@ void perf_prepare_sample(struct perf_event_header >> > *header, >> > struct

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On Wed, Jun 28, 2017 at 09:48:27AM -0700, Kyle Huey wrote: > On Wed, Jun 28, 2017 at 3:56 AM, Mark Rutland wrote: > > @@ -6101,6 +6116,12 @@ void perf_prepare_sample(struct perf_event_header > > *header, > > struct perf_output_handle handle; > > struct

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On Wed, Jun 28, 2017 at 09:48:27AM -0700, Kyle Huey wrote: > On Wed, Jun 28, 2017 at 3:56 AM, Mark Rutland wrote: > > @@ -6101,6 +6116,12 @@ void perf_prepare_sample(struct perf_event_header > > *header, > > struct perf_output_handle handle; > > struct perf_event_header header; >

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On Wed, Jun 28, 2017 at 3:56 AM, Mark Rutland wrote: > On Wed, Jun 28, 2017 at 11:12:48AM +0100, Mark Rutland wrote: >> On Tue, Jun 27, 2017 at 09:51:00PM -0700, Kyle Huey wrote: > >> As we're trying to avoid smapling state, I think we can move the check >> into

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On Wed, Jun 28, 2017 at 3:56 AM, Mark Rutland wrote: > On Wed, Jun 28, 2017 at 11:12:48AM +0100, Mark Rutland wrote: >> On Tue, Jun 27, 2017 at 09:51:00PM -0700, Kyle Huey wrote: > >> As we're trying to avoid smapling state, I think we can move the check >> into perf_prepare_sample() or

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On Wed, Jun 28, 2017 at 08:40:30AM -0400, Vince Weaver wrote: > On Wed, 28 Jun 2017, Mark Rutland wrote: > > > On Wed, Jun 28, 2017 at 11:12:48AM +0100, Mark Rutland wrote: > > > Instead of bailing out early in perf_event_overflow, we can bail prior > > to performing the actual sampling in

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On Wed, Jun 28, 2017 at 08:40:30AM -0400, Vince Weaver wrote: > On Wed, 28 Jun 2017, Mark Rutland wrote: > > > On Wed, Jun 28, 2017 at 11:12:48AM +0100, Mark Rutland wrote: > > > Instead of bailing out early in perf_event_overflow, we can bail prior > > to performing the actual sampling in

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On Wed, 28 Jun 2017, Mark Rutland wrote: > On Wed, Jun 28, 2017 at 11:12:48AM +0100, Mark Rutland wrote: > Instead of bailing out early in perf_event_overflow, we can bail prior > to performing the actual sampling in __perf_event_output(). This avoids > the information leak, but preserves the

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On Wed, 28 Jun 2017, Mark Rutland wrote: > On Wed, Jun 28, 2017 at 11:12:48AM +0100, Mark Rutland wrote: > Instead of bailing out early in perf_event_overflow, we can bail prior > to performing the actual sampling in __perf_event_output(). This avoids > the information leak, but preserves the

[PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On Wed, Jun 28, 2017 at 11:12:48AM +0100, Mark Rutland wrote: > On Tue, Jun 27, 2017 at 09:51:00PM -0700, Kyle Huey wrote: > As we're trying to avoid smapling state, I think we can move the check > into perf_prepare_sample() or __perf_event_output(), where that state is > actually sampled. I'll

[PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On Wed, Jun 28, 2017 at 11:12:48AM +0100, Mark Rutland wrote: > On Tue, Jun 27, 2017 at 09:51:00PM -0700, Kyle Huey wrote: > As we're trying to avoid smapling state, I think we can move the check > into perf_prepare_sample() or __perf_event_output(), where that state is > actually sampled. I'll