From: Torsten Duwe <duwe@lst.de>
To: Petr Mladek <pmladek@suse.com>
Cc: jeyu@redhat.com, jkosina@suse.cz, linux-kernel@vger.kernel.org,
rostedt@goodmis.org, kamalesh@linux.vnet.ibm.com,
linuxppc-dev@ozlabs.org, live-patching@vger.kernel.org,
mbenes@suse.cz
Subject: Re: [PATCH][v4] livepatch/ppc: Enable livepatching on powerpc
Date: Fri, 4 Mar 2016 20:22:22 +0100 [thread overview]
Message-ID: <20160304192222.GA31341@lst.de> (raw)
In-Reply-To: <20160304181657.GA30434@lst.de>
On Fri, Mar 04, 2016 at 07:16:57PM +0100, Torsten Duwe wrote:
> On Fri, Mar 04, 2016 at 02:01:37PM +0100, Petr Mladek wrote:
> >
> > Do I understand it correctly that we could not patch functions that
> > pass arguments on the stack with this implementation? If yes, how hard
> > would be to get it working, please? At least, it would be great to
> > catch this problem and handle it with grace. Otherwise, it might
> > be hard to debug.
>
> No, those functions only require special attention.
So far it's correct. It's been a while since I wrote that code.
> I needed _any_ location to store the caller's TOC;
> and the stack is thread-safe and recursion-safe.
> The current caller's frame is already full so I had
> to create a new one.
Correction: the TOC can be stored in the caller's stack frame at
the usual location. Only the restore instruction is a problem.
> A patch function could e.g. grab that TOC value in a
> prologue and then pop that stack frame. Or it could
> add those 32 bytes to the assumed arguments' stack offsets.
So one solution could be to call the patch function via a small
trampoline or pre-prologue that just pops that frame, and have
the patch function restore R2 manually at the end.
Sorry for the confusion,
Torsten
next prev parent reply other threads:[~2016-03-04 19:22 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-03 16:52 [PATCH][v4] livepatch/ppc: Enable livepatching on powerpc Petr Mladek
2016-03-03 20:43 ` Balbir Singh
2016-03-04 6:08 ` Kamalesh Babulal
2016-03-04 7:58 ` Michael Ellerman
2016-03-04 9:31 ` Miroslav Benes
2016-03-07 3:29 ` Michael Ellerman
2016-03-04 8:06 ` How to merge? (was Re: [PATCH][v4] livepatch/ppc: Enable livepatching on powerpc) Michael Ellerman
2016-03-04 8:56 ` Jiri Kosina
2016-03-07 10:06 ` Michael Ellerman
2016-03-07 22:52 ` Jiri Kosina
2016-03-07 23:20 ` Michael Ellerman
2016-03-08 1:53 ` Steven Rostedt
2016-03-07 23:22 ` Josh Poimboeuf
2016-03-04 12:42 ` [PATCH][v4] livepatch/ppc: Enable livepatching on powerpc Torsten Duwe
2016-03-04 13:01 ` Petr Mladek
2016-03-04 18:16 ` Torsten Duwe
2016-03-04 19:22 ` Torsten Duwe [this message]
2016-03-08 11:14 ` Torsten Duwe
2016-03-06 23:55 ` Balbir Singh
2016-03-04 21:56 ` Josh Poimboeuf
2016-03-08 21:42 ` Steven Rostedt
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=20160304192222.GA31341@lst.de \
--to=duwe@lst.de \
--cc=jeyu@redhat.com \
--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=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.