linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Ellerman <mpe@ellerman.id.au>
To: Torsten Duwe <duwe@lst.de>
Cc: ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ppc64 ftrace: mark data_access callees "notrace" (pt.1)
Date: Fri, 15 May 2015 11:34:47 +1000	[thread overview]
Message-ID: <1431653687.13498.1.camel@ellerman.id.au> (raw)
In-Reply-To: <20150513161100.GA1619@lst.de>

On Wed, 2015-05-13 at 18:11 +0200, Torsten Duwe wrote:
> In order to avoid an endless recursion, functions that may get
> called from the data access handler must not call into tracing
> functions, which may cause data access faults ;-)
> 
> Advancing from my previous approach that lavishly compiled whole
> subdirs without the profiling switches, this is more fine-grained
> (but probably yet incomplete). This patch is necessary albeit not
> sufficient for FTRACE_WITH_REGS on ppc64.

There's got to be a better solution than this. The chance that you've correctly
annotated every function is basically 0, and the chance that we correctly add
it to every new or modififed function in the future is also 0.

I don't mean that as a criticism of you, but rather the technique. For starters
I don't see any annotations in 32-bit code, or in the BookE code etc.

Can you give us more details on what goes wrong without these annotations?

cheers



  reply	other threads:[~2015-05-15  1:34 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-13 16:11 [PATCH] ppc64 ftrace: mark data_access callees "notrace" (pt.1) Torsten Duwe
2015-05-15  1:34 ` Michael Ellerman [this message]
2015-05-15  8:45   ` Torsten Duwe
2015-05-16  8:05     ` Torsten Duwe
2015-05-18 12:29       ` Jiri Kosina
2015-05-19  3:27         ` Michael Ellerman
2015-05-19  9:52           ` Jiri Kosina
2015-06-03 13:02             ` [PATCH 0/4] ppc64 ftrace implementation Torsten Duwe
2015-06-03 13:08               ` [PATCH 1/4] " Torsten Duwe
2015-06-08 15:30                 ` Steven Rostedt
2015-06-08 15:57                   ` Torsten Duwe
2015-06-03 13:10               ` [PATCH 2/4] ppc64 ftrace configuration Torsten Duwe
2015-06-03 13:15               ` [PATCH 3/4] ppc64 ftrace: spare early boot and low level code Torsten Duwe
2015-06-03 13:22               ` [PATCH 4/4] ppc64 ftrace recursion protection Torsten Duwe
2015-05-20  9:03           ` [PATCH] ppc64 ftrace: mark data_access callees "notrace" (pt.1) Torsten Duwe
2015-05-26 14:34             ` Torsten Duwe

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=1431653687.13498.1.camel@ellerman.id.au \
    --to=mpe@ellerman.id.au \
    --cc=duwe@lst.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.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).