Re: perf: record segfaults for cycles event when collecting data on a VM

[Ingo Molnar <mingo@elte.hu>]

* Joerg Roedel <joerg.roedel@amd.com> wrote:

> On Thu, Feb 09, 2012 at 08:30:24AM +0100, Ingo Molnar wrote:
> > 
> > * Joerg Roedel <joerg.roedel@amd.com> wrote:
> > 
> > > > which makes sense. It forces 
> > > > perf_session__find_machine_for_cpumode() to return the host 
> > > > machine always.
> > > 
> > > Great, thanks. I will send two patches tomorrow to fix Jason's 
> > > problem and change the default for perf_guest.
> > 
> > Well, if the crash is fixed then the the default can stay, 
> > right?
> 
> David's crash is fixed by changing the default back to its 
> original value :)

Then that's the wrong fix really.

> > Generally we should treat all input data in a perf.data or even 
> > the bits we get in the ring-buffer as external data that has to 
> > be checked carefully, with no assumptions made about data.
> 
> Well, there are two options:
> 
> 	1) Make sure machine == NULL does not happen. Changing the
> 	   default of perf_guest back to false does exactly this for
> 	   David's problem.

So what if it's turned on by the user? Do we still crash 
occasionally?

> 	2) Make sure that a machine == NULL pointer is never
> 	   dereferenced
> 
> I was going to fix it with option 1. Do you suggest option 2 is better?

Looks like the better fix. You said:

> Bottom line is that the perf-tool may receive samples tagged 
> as GUEST_KERNEL even when guest-sampling is disabled (probably 
> a race-condition). The perf-tool can not find a valid machine 
> pointer for such a sample and passes NULL down to the other 
> functions. And some functions don't seem to handle this.

tooling should never be surprised by getting some unexpected 
sample via the perf.data or the ring-buffer - regardless of 
whether that functionality is default enabled or manually 
enabled.

Thanks,

	Ingo