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

Ingo Molnar
2012-02-09T13:35:07Z

* 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