linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Michael Ellerman <mpe@ellerman.id.au>
To: Torsten Duwe <duwe@lst.de>
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 v8 1/8] ppc64 (le): prepare for -mprofile-kernel
Date: Wed, 17 Feb 2016 22:39:13 +1100	[thread overview]
Message-ID: <1455709153.23614.4.camel@ellerman.id.au> (raw)
In-Reply-To: <20160217113022.GA9578@lst.de>

On Wed, 2016-02-17 at 12:30 +0100, Torsten Duwe wrote:
> On Wed, Feb 17, 2016 at 09:55:40PM +1100, Michael Ellerman wrote:
> > 
> > On a kernel built with the 2 instruction version this will fault when the
> > function we're looking at is located at the beginning of a page. Because
> > instruction[-3] goes off the front of the mapping.
> > 
> > We can probably fix that. But it's still a bit dicey.
> 
> Not necessarily. Now that it's a separate function, it can be nested a bit deeper,
> so we don't take chances on compiler optimisation:
> 
> if (instruction[-2] == PPC_INST_STD_LR) /* where should R0 come from? there must be... */
>   {
>     if (instruction[-3] == PPC_INST_MFLR)
>       return 1;
>   }
> else if (instruction[-2] == PPC_INST_MFLR)
>     return 1;
> return 0;

Yeah true that should work in practice.

It's still trivial to construct a module that will oops the loader, but I guess
that's always been true.

> > I'm wondering if we want to just say we only support the 2 instruction version.
> > Currently that means GCC 6 only, or a distro compiler with the backport of
> > e95d0248dace. But we could also ask GCC to backport it to 4.9 and 5.
> 
> IMHO that's a too weak reason for a too strong limitation. OTOH getting everyone
> to use the 2 insn version sounds appealing...

Fair enough. I'm just trying to manage the complexity explosion.

I'd certainly advocate that you backport it to your toolchain.

> Is e95d0248dace self-sufficient or does it depend on other improvements?

AFAIK it's self sufficient, it just deletes a single line. I'll ask the GCC
guys tomorrow if they can backport it if you don't beat me to it :)

cheers

  reply	other threads:[~2016-02-17 11:39 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-10 17:29 [PATCH v8 0/8] ftrace with regs + live patching for ppc64 LE (ABI v2) Torsten Duwe
2016-01-28 15:32 ` [PATCH v8 8/8] livepatch: Detect offset for the ftrace location during build Torsten Duwe
2016-02-12 16:13   ` Balbir Singh
2016-02-12 16:45     ` Petr Mladek
2016-02-13  1:33       ` Balbir Singh
2016-02-16  5:47       ` Kamalesh Babulal
2016-02-16  8:23         ` Torsten Duwe
2016-02-16 10:30           ` Kamalesh Babulal
2016-02-16 10:39             ` Torsten Duwe
2016-02-16 13:57               ` Petr Mladek
2016-02-17  3:08                 ` Michael Ellerman
2016-02-23 17:00                   ` Torsten Duwe
2016-02-24  6:37                     ` Balbir Singh
2016-02-24  6:55                       ` Balbir Singh
2016-02-24  9:23                         ` Torsten Duwe
2016-02-24 11:22                           ` Balbir Singh
2016-02-24  7:51                     ` Kamalesh Babulal
2016-02-10 16:21 ` [PATCH v8 1/8] ppc64 (le): prepare for -mprofile-kernel Torsten Duwe
2016-02-17 10:55   ` Michael Ellerman
2016-02-17 11:30     ` Torsten Duwe
2016-02-17 11:39       ` Michael Ellerman [this message]
2016-02-10 16:22 ` [PATCH v8 2/8] ppc64le FTRACE_WITH_REGS implementation Torsten Duwe
2016-02-10 16:22 ` [PATCH v8 3/8] ppc use ftrace_modify_all_code default Torsten Duwe
2016-02-10 16:25 ` [PATCH v8 4/8] ppc64 ftrace_with_regs configuration variables Torsten Duwe
2016-02-11  7:48   ` Balbir Singh
2016-02-11  8:39     ` Kamalesh Babulal
2016-02-11  9:35       ` Balbir Singh
2016-02-11 13:00         ` Murali Sampath
2016-02-11 13:00         ` Murali Sampath
2016-02-11  8:42     ` Torsten Duwe
2016-02-11  9:34       ` Balbir Singh
2016-02-15 10:27       ` Michael Ellerman
2016-02-15 12:56         ` Jiri Kosina
2016-02-15 14:04         ` Torsten Duwe
2016-02-15 22:21           ` Torsten Duwe
2016-02-16  4:53             ` Balbir Singh
2016-02-16 10:09           ` Michael Ellerman
2016-02-16 10:35             ` Torsten Duwe
2016-02-10 16:27 ` [PATCH v8 5/8] ppc64 ftrace_with_regs: disable profiling for some files Torsten Duwe
2016-02-10 16:34 ` [PATCH v8 6/8] Implement kernel live patching for ppc64le (ABIv2) Torsten Duwe
2016-02-11  9:01   ` Miroslav Benes
2016-02-10 16:36 ` [PATCH v8 7/8] Enable LIVEPATCH to be configured on ppc64le and add livepatch.o if it is selected Torsten Duwe
2016-02-11  6:18 ` [PATCH v8 0/8] ftrace with regs + live patching for ppc64 LE (ABI v2) Balbir Singh
2016-02-11  8:38   ` 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=1455709153.23614.4.camel@ellerman.id.au \
    --to=mpe@ellerman.id.au \
    --cc=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=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).