linuxppc-dev.lists.ozlabs.org archive mirror
 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>,
	Balbir Singh <bsingharora@gmail.com>,
	"Naveen N . Rao" <naveen.n.rao@linux.vnet.ibm.com>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Jessica Yu <jeyu@kernel.org>,
	Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>,
	Aravinda Prasad <aravinda@linux.vnet.ibm.com>,
	linuxppc-dev@lists.ozlabs.org, live-patching@vger.kernel.org
Subject: Re: [PATCH v2] kernel/module_64.c: Add REL24 relocation support of livepatch symbols
Date: Tue, 17 Oct 2017 16:47:33 +0200	[thread overview]
Message-ID: <20171017144733.GB2136@lst.de> (raw)
In-Reply-To: <9f388c9a-8d74-865a-b113-f77322918b39@linux.vnet.ibm.com>

On Fri, Oct 06, 2017 at 11:27:42AM +0530, Kamalesh Babulal wrote:
>
> Consider the livepatch sequence[1]. Where function A calls B, B is the
> function which has been livepatched and the call to function B is
> redirected to patched version P. P calls the function C in M2, whereas
> C was local to the function B and have became SHN_UNDEF in function P.
> Local call becoming global.
>
>   +--------+            +--------+    +--------+      +--------+
>   |        |   +--------+--------+--->|        |  +-->|        |
>   |  A     |   |        |  B     |    |  F     |  |   |  P     |
>   |        |   |        |        |    |        +--+   |        |
>   |        +---+        |        |    |        |<-+   |        |
>   |        |<--+   +----+   C    |    |        |  |   |        |
>   |        |   |   | +->|        |    |        |  |   |        |<---+
>   | K / M1 |   |   | |  | K / M2 |  +-+ Kernel |  +---+ Mod3   +--+ |
>   +--------+   |   | |  +--------+  | +--------+      +--------+  | |
>                |   | |              |                             | |
>                +---+-+--------------+                             | |
>                    | |                                            | |
>                    | +--------------------------------------------+ |
>                    +------------------------------------------------+
>
>
> Handling such call with regular stub, triggers another error:
>
> module_64: kpatch_meminfo: Expect noop after relocate, got 3d220000
>
> Every branch to SHN_UNDEF is followed by a nop instruction, that gets
> overwritten by an instruction to restore TOC with r2 value that get
> stored onto the stack, before calling the function via global entry
> point.
>
> Given that C was local to function B, it does not store/restore TOC as
> they are not expected to be clobbered for functions called via local
> entry point.

Can you please provide example source code of Mod3 and C? If P calls C, this
is a regular global call, the TOC is saved by the stub and restored after the
call instruction. Why do you think this is not the case? 

	Torsten

  reply	other threads:[~2017-10-17 14:47 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-04 15:25 [PATCH v2] kernel/module_64.c: Add REL24 relocation support of livepatch symbols Kamalesh Babulal
2017-10-05  6:56 ` Naveen N . Rao
2017-10-05 12:43 ` Torsten Duwe
2017-10-06  5:43   ` Kamalesh Babulal
2017-10-11  9:44     ` Kamalesh Babulal
2017-10-06  5:57   ` Kamalesh Babulal
2017-10-17 14:47     ` Torsten Duwe [this message]
2017-10-18  6:17       ` Kamalesh Babulal
2017-10-20 12:07         ` Torsten Duwe
2017-10-21  0:59           ` Balbir Singh
2017-10-23  8:19             ` Kamalesh Babulal
2017-12-12 11:39               ` [PATCH] On ppc64le we HAVE_RELIABLE_STACKTRACE Torsten Duwe
2017-12-12 12:12                 ` Miroslav Benes
2017-12-12 13:02                   ` Torsten Duwe
2018-02-27 16:09                   ` [PATCH 2/2] ppc64le save_stack_trace_tsk_reliable (Was: HAVE_RELIABLE_STACKTRACE) Torsten Duwe
2018-03-08 21:43                     ` Balbir Singh
2018-03-09 15:54                       ` Torsten Duwe
2017-12-12 14:05                 ` [PATCH] On ppc64le we HAVE_RELIABLE_STACKTRACE Josh Poimboeuf
2017-12-15  9:40                   ` Nicholas Piggin
2017-12-18  2:58                     ` Josh Poimboeuf
2017-12-18  3:39                       ` Balbir Singh
2017-12-18  4:01                         ` Josh Poimboeuf
2017-12-18  5:33                       ` Nicholas Piggin
2017-12-18 18:56                         ` Josh Poimboeuf
2017-12-19  2:46                           ` Nicholas Piggin
2017-12-19 11:28                           ` Torsten Duwe
2017-12-19 21:46                             ` Josh Poimboeuf
2017-12-21 12:10                               ` Michael Ellerman
2017-12-23  4:00                                 ` Josh Poimboeuf

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=20171017144733.GB2136@lst.de \
    --to=duwe@lst.de \
    --cc=ananth@linux.vnet.ibm.com \
    --cc=aravinda@linux.vnet.ibm.com \
    --cc=bsingharora@gmail.com \
    --cc=jeyu@kernel.org \
    --cc=jpoimboe@redhat.com \
    --cc=kamalesh@linux.vnet.ibm.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=live-patching@vger.kernel.org \
    --cc=mpe@ellerman.id.au \
    --cc=naveen.n.rao@linux.vnet.ibm.com \
    /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).