All of lore.kernel.org
 help / color / mirror / Atom feed
From: Torsten Duwe <duwe@lst.de>
To: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>,
	Petr Mladek <pmladek@suse.com>,
	jeyu@redhat.com, jkosina@suse.cz, jikos@kernel.org,
	linux-kernel@vger.kernel.org, rostedt@goodmis.org,
	linuxppc-dev@ozlabs.org, live-patching@vger.kernel.org,
	mbenes@suse.cz
Subject: Re: [PATCH/RFC] ppc64 livepatch: frameless klp_return_helper using odd TOC
Date: Thu, 24 Mar 2016 11:27:57 +0100	[thread overview]
Message-ID: <20160324102757.GA29197@lst.de> (raw)
In-Reply-To: <20160324101453.GA1445@linux.vnet.ibm.com>

On Thu, Mar 24, 2016 at 03:44:55PM +0530, Kamalesh Babulal wrote:
> * Torsten Duwe <duwe@lst.de> [2016-03-23 16:58:58]:
> 
> > 
> > Since nobody liked the extra stack frame nor its workarounds, here is
> > the next attempt. Assumptions:
> > 
> > 1. Heuristics are bad. The better they are, the more subtly the
> >    way they might fail.
> > 
> > 2. The TOC pointer is usually dividable by 4, if not by 8. An odd
> >    value never occurs.
> > 
> > Conclusively, this patch unambiguously creates an odd TOC value when
> > an ftraced function's global entry point is used. Ftrace_caller will
> > then immediately fix it, and alongside gather the information whether
> > the made call was local or global.
> > 
> > In case of live patching this information is furthermore used to decide
> > whether a klp_return_helper needs to be inserted or not.
> > CAVEAT: any frameless klp_return_helper does not play well with
> > sibling calls! There's an emergency exit that might work, at worst
> > it will cause an oops, but it surely avoids a lockup.
> > At least the live patching modules on ppc64le will need to be compiled
> > using the -fno-optimize-sibling-calls compiler flag!
> > 
> > Thanks go to Michael Matz and Richard Biener for reassurance about
> > heuristics and pointers to the compiler flag.
> > 
> > Signed-off-by: Torsten Duwe <duwe@suse.de>
> 
> Hi Torsten,
> 
> Should this patch be applied over Petr Mladek's v4 ?

Yes. Just omit the changes it makes to entry_64.S and use this instead.

	Torsten

  reply	other threads:[~2016-03-24 10:28 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-23 15:58 [PATCH/RFC] ppc64 livepatch: frameless klp_return_helper using odd TOC Torsten Duwe
2016-03-24  2:23 ` Balbir Singh
2016-03-24  8:04   ` Torsten Duwe
2016-03-24 11:06     ` Michael Ellerman
2016-03-24 10:14 ` Kamalesh Babulal
2016-03-24 10:27   ` Torsten Duwe [this message]
2016-03-24 15:58     ` Kamalesh Babulal

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=20160324102757.GA29197@lst.de \
    --to=duwe@lst.de \
    --cc=jeyu@redhat.com \
    --cc=jikos@kernel.org \
    --cc=jkosina@suse.cz \
    --cc=kamalesh@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.