Messages in this thread | | | From | Vince Weaver <> | Date | Wed, 28 Jun 2017 08:40:30 -0400 (EDT) | Subject | 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 generation of the signal. > > Since we don't place any sample data into the ring buffer, the signal is > arguably spurious. However, a userspace ringbuffer consumer can already > consume data prior to taking the associated signals, and therefore must > handle spurious signals to operate correctly. Thus, this signal > shouldn't be harmful.
this could still break some of my perf_event validation tests.
Ones that set up a sampling event for every 1M instructions, run for 100M instructions, and expect there to be 100 samples received.
If we're so worried about info leakage, can't we just zero-out the problem address (or randomize the kernel address) rather than just pretending the interrupt didn't happen?
Vince
| |