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