[lkml]   [2016]   [Feb]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v7 06/10] ppc64 ftrace: disable profiling for some functions
On Wed, Feb 10, 2016 at 12:50:38PM +1100, Michael Ellerman wrote:
> On Mon, 2016-01-25 at 16:31 +0100, Torsten Duwe wrote:
> > At least POWER7/8 have MMUs that don't completely autoload;
> > a normal, recoverable memory fault might pass through these functions.
> > If a dynamic tracer function causes such a fault, any of these functions
> > being traced with -mprofile-kernel may cause an endless recursion.
> I'm not really happy with this one, still :)

I understand :)

> At the moment I can trace these without any problems, with either ftrace or
> kprobes, but obviously it was causing you some trouble. So I'd like to
> understand why you were having issues when regular tracing doesn't.

It was causing huge trouble during development. Make the smallest mistake
and the machine appears to freeze, unless you happen to have a gdb
beneath the VM, which tells you that it's "only" locking rock-hard into
an endless recursion. Hint: printk() is part of the recurse, usually :-/

> If it's the case that tracing can work for these functions, but live patching
> doesn't (for some reason), then maybe these should be blocked by the live
> patching infrastructure rather than at the ftrace/kprobes level.

Now with a matured patch set, the machine survives up to the point where the
NOPs are placed and all is fine. (until someone places probes there :)

But I still have a bad feeling about this. On other architectures, this
functionality is done in hardware; the functions cannot be traced either,
and the don't break (usually ;) I would rather not instrument them.

But if you don't like this patch, and it strictly isn't neccessary --
here you go: v8.


 \ /
  Last update: 2016-02-10 19:21    [W:0.065 / U:16.980 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site