linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Torsten Duwe <duwe@lst.de>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: Jiri Kosina <jkosina@suse.cz>, Miroslav Benes <mbenes@suse.cz>,
	Petr Mladek <pmladek@suse.com>, Jessica Yu <jeyu@redhat.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
	live-patching@vger.kernel.org
Subject: Re: [PATCH v7 06/10] ppc64 ftrace: disable profiling for some functions
Date: Wed, 10 Feb 2016 19:01:12 +0100	[thread overview]
Message-ID: <20160210180112.GB19199@lst.de> (raw)
In-Reply-To: <1455069038.7576.6.camel@ellerman.id.au>

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

  reply	other threads:[~2016-02-10 18:01 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-04 14:29 [PATCH v7 00/10] ftrace with regs + live patching for ppc64 LE (ABI v2) Torsten Duwe
2016-01-25 15:26 ` [PATCH v7 01/10] ppc64 (le): prepare for -mprofile-kernel Torsten Duwe
2016-01-25 15:27 ` [PATCH v7 02/10] ppc64le FTRACE_WITH_REGS implementation Torsten Duwe
2016-01-25 15:29 ` [PATCH v7 03/10] ppc use ftrace_modify_all_code default Torsten Duwe
2016-01-25 15:29 ` [PATCH v7 04/10] ppc64 ftrace_with_regs configuration variables Torsten Duwe
2016-02-05 14:05   ` Petr Mladek
2016-02-05 14:48     ` Steven Rostedt
2016-02-05 16:18       ` Petr Mladek
2016-02-05 16:30         ` Steven Rostedt
2016-02-06 10:32         ` Torsten Duwe
2016-02-08 10:34           ` Petr Mladek
2016-02-08 12:12             ` Torsten Duwe
2016-02-08 15:23               ` Petr Mladek
2016-02-08 15:49                 ` Steven Rostedt
2016-02-08 16:32                   ` Petr Mladek
2016-02-09  9:02                   ` Torsten Duwe
2016-01-25 15:30 ` [PATCH v7 05/10] ppc64 ftrace_with_regs: spare early boot and low level Torsten Duwe
2016-01-25 15:31 ` [PATCH v7 06/10] ppc64 ftrace: disable profiling for some functions Torsten Duwe
2016-02-10  1:50   ` Michael Ellerman
2016-02-10 18:01     ` Torsten Duwe [this message]
2016-01-25 15:31 ` [PATCH v7 07/10] ppc64 ftrace: disable profiling for some files Torsten Duwe
2016-02-10  0:33   ` Michael Ellerman
2016-02-10 17:50     ` Torsten Duwe
2016-01-25 15:33 ` [PATCH v7 08/10] Implement kernel live patching for ppc64le (ABIv2) Torsten Duwe
2016-01-25 15:33 ` [PATCH v7 09/10] Enable LIVEPATCH to be configured on ppc64le and add livepatch.o if it is selected Torsten Duwe
2016-01-28 15:32 ` [PATCH v7 10/10] livepatch: Detect offset for the ftrace location during build Petr Mladek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160210180112.GB19199@lst.de \
    --to=duwe@lst.de \
    --cc=jeyu@redhat.com \
    --cc=jkosina@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=live-patching@vger.kernel.org \
    --cc=mbenes@suse.cz \
    --cc=mpe@ellerman.id.au \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).