From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1752159AbdGDKEW (ORCPT <rfc822;w@1wt.eu>);
        Tue, 4 Jul 2017 06:04:22 -0400
Received: from mail-wm0-f66.google.com ([74.125.82.66]:33051 "EHLO
        mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751845AbdGDKEU (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 4 Jul 2017 06:04:20 -0400
Date: Tue, 4 Jul 2017 12:04:15 +0200
From: Ingo Molnar <mingo@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Mark Rutland <mark.rutland@arm.com>, Kyle Huey <me@kylehuey.com>,
        Vince Weaver <vincent.weaver@maine.edu>,
        "Jin, Yao" <yao.jin@linux.intel.com>, stable@vger.kernel.org,
        Alexander Shishkin <alexander.shishkin@linux.intel.com>,
        Arnaldo Carvalho de Melo <acme@redhat.com>,
        Jiri Olsa <jolsa@redhat.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Namhyung Kim <namhyung@kernel.org>,
        Stephane Eranian <eranian@google.com>,
        Thomas Gleixner <tglx@linutronix.de>, acme@kernel.org,
        jolsa@kernel.org, kan.liang@intel.com,
        Will Deacon <will.deacon@arm.com>, gregkh@linuxfoundation.org,
        "Robert O'Callahan" <robert@ocallahan.org>,
        open list <linux-kernel@vger.kernel.org>
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)
Message-ID: <20170704100414.zieuyviz37pw3sff@gmail.com>
References: <CAP045Ap8cMx6mzSgcQ3n3bnh_8GJuCp7_KZe_5ZTCR_K6cPTLw@mail.gmail.com>
 <CAP045Ao2=6A7GEhBfmY0gZ2g=urL5U4R5ywLsTo4Yb6Tk1M8Cw@mail.gmail.com>
 <2256f9b5-1277-c4b1-1472-61a10cd1db9a@linux.intel.com>
 <CAP045AryPCUTO92S3hmrkag3D7NqgJM-hK82a7iKm9s-rWdn1w@mail.gmail.com>
 <20170628101248.GB5981@leverpostej>
 <20170628105600.GC5981@leverpostej>
 <CAP045ApjOeng6M9kqwbNpv5OTN=_Gkk2MHREztzZV_CecqpmxQ@mail.gmail.com>
 <20170628174900.GG8252@leverpostej>
 <20170629081233.7muy7k447pc5njmg@gmail.com>
 <20170704090647.dbvrpnah6d47txdx@hirez.programming.kicks-ass.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170704090647.dbvrpnah6d47txdx@hirez.programming.kicks-ass.net>
User-Agent: NeoMutt/20170113 (1.7.2)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


* Peter Zijlstra <peterz@infradead.org> wrote:

> On Thu, Jun 29, 2017 at 10:12:33AM +0200, Ingo Molnar wrote:
> > 
> > * Mark Rutland <mark.rutland@arm.com> 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 
> > hardware on existing systems there's really just two choices:
> > 
> >  - Lose the sample (and signal it as a lost sample)
> > 
> >  - Keep the sample but change the sensitive kernel-internal address to something 
> >    that is not sensitive: 0 or -1 works, but we could perhaps also return a 
> >    well-known user-space address such as the vDSO syscall trampoline or such?
> > 
> > there's no other option really.
> > 
> > I'd lean towards Vince's take: losing samples is more surprising than getting the 
> > occasional sample with some sanitized data in it.
> > 
> > If we make the artificial data still a meaningful user-space address, related to 
> > kernel entries, then it might even be a bonus, as users would learn to recognize 
> > it as: 'oh, skid artifact, I know about that'.
> 
> So while we could easily fake SAMPLE_IP to do as you suggest, other
> entries might be much harder to fake. That said, I have no problems with
> just 0 stuffing them.
> 
> The only real problem is determining how much to stuff I suppose.

I think the RIP is the most important one to fix up in an informative fashion 
(instead of just zeroing it out), so that mainstream users of 'perf top' or
'perf report' have a chance to see that certain entries have this skid artifact.

The other registers should be zeroed out once we stop trusting a sample.

Thanks,

	Ingo