[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190131131020.GX6118@tassilo.jf.intel.com>
Date: Thu, 31 Jan 2019 05:10:20 -0800
From: Andi Kleen <ak@...ux.intel.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: kan.liang@...ux.intel.com, acme@...nel.org, tglx@...utronix.de,
mingo@...hat.com, linux-kernel@...r.kernel.org, eranian@...gle.com,
jolsa@...hat.com, namhyung@...nel.org,
Andy Lutomirski <luto@...capital.net>
Subject: Re: [PATCH V3 01/13] perf/core, x86: Add PERF_SAMPLE_DATA_PAGE_SIZE
>
> Aside from all the missin {}, I'm fairly sure this is broken since this
> happens from NMI context. This can interrupt switch_mm() and things like
> use_temporary_mm().
So the concern is that the sample is from before the switch, and then
looks it up in the wrong page tables if the PMI happens after the switch
due to sampling skid?
First this can happen only with PEBS, which doesn't have that
bad worst case skid (perhaps tens of cycles)
I doubt it is very likely because this problem could only happen
for user addresses because kernel page tables don't change.
But we would be in the middle of the context
switch (or use_temporary_mm) here, and there should be no
user space accesses within a tens of cycle window
(except perhaps for the rseq address, but that's not a very
interesting case)
I assume the use_temporary_mm() cases are similar.
I suppose we could enforce flushing the PMU on such context switches,
but I would suspect while it's a valid theoretical problem,
it's unlikely to be a real problem in practice.
Likely it means that large buffer PEBS cannot be ever used
with this option, but I guess that's ok.
-Andi
Powered by blists - more mailing lists