Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1330844 > unrolled thread

Re: [PATCH v7 06/10] ppc64 ftrace: disable profiling for some functions

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v7 06/10] ppc64 ftrace: disable profiling for some  functions Michael Ellerman <mpe@ellerman.id.au> - 2016-02-10 03:00 +0100
    Re: [PATCH v7 06/10] ppc64 ftrace: disable profiling for some  functions Torsten Duwe <duwe@lst.de> - 2016-02-10 19:10 +0100

#1330844 — Re: [PATCH v7 06/10] ppc64 ftrace: disable profiling for some functions

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 :)

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.

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.

cheers

[toc] | [next] | [standalone]

#1331409

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.

	Torsten

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web