[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200604160357.GF3976@hirez.programming.kicks-ass.net>
Date: Thu, 4 Jun 2020 18:03:57 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Andrey Konovalov <andreyknvl@...gle.com>
Cc: Marco Elver <elver@...gle.com>, Borislav Petkov <bp@...en8.de>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...nel.org>,
clang-built-linux <clang-built-linux@...glegroups.com>,
"Paul E . McKenney" <paulmck@...nel.org>,
Dmitry Vyukov <dvyukov@...gle.com>,
Alexander Potapenko <glider@...gle.com>,
kasan-dev <kasan-dev@...glegroups.com>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH -tip] kcov: Make runtime functions noinstr-compatible
On Thu, Jun 04, 2020 at 04:02:54PM +0200, Andrey Konovalov wrote:
> On Thu, Jun 4, 2020 at 1:09 PM Peter Zijlstra <peterz@...radead.org> wrote:
> > That whole kcov_remote stuff confuses me.
> >
> > KCOV_ENABLE() has kcov_fault_in_area(), which supposedly takes the
> > vmalloc faults for the current task, but who does it for the remote?
>
> Hm, no one. This might be an issue, thanks for noticing!
>
> > Now, luckily Joerg went and ripped out the vmalloc faults, let me check
> > where those patches are... w00t, they're upstream in this merge window.
>
> Could you point me to those patches?
>
> Even though it might work fine now, we might get issues if we backport
> remote kcov to older kernels.
Thinking more about this; you can't actually pre-fault for kernel
threads, as kernel threads will run with the mm of whatever regular
thread ran before them, and who knows if they have that vmalloc region
faulted in.
So Joerg's patches are pretty much the only way to guarantee remotes
will not his the vmalloc fault.
Powered by blists - more mailing lists