public inbox for live-patching@vger.kernel.org
 help / color / mirror / Atom feed
From: Josh Poimboeuf <jpoimboe@kernel.org>
To: Song Liu <song@kernel.org>
Cc: live-patching@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-kernel@vger.kernel.org, Nicholas Piggin <npiggin@gmail.com>
Subject: Re: [PATCH 2/2] powerpc/module_64: Fix "expected nop" error on module re-patching
Date: Wed, 25 Jan 2023 10:53:16 -0800	[thread overview]
Message-ID: <20230125185316.ebvxecd7gsvgtudr@treble> (raw)
In-Reply-To: <CAPhsuW45k8Avx=Zfid1pxaeHAbLGgOcxbN_=DQOb8WdPx7fB+Q@mail.gmail.com>

On Wed, Jan 25, 2023 at 09:36:02AM -0800, Song Liu wrote:
> On Wed, Jan 25, 2023 at 8:46 AM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
> >
> > On Tue, Jan 24, 2023 at 10:09:56PM -0800, Song Liu wrote:
> > > > @@ -514,9 +515,18 @@ static int restore_r2(const char *name, u32 *instruction, struct module *me)
> > > >         if (!instr_is_relative_link_branch(ppc_inst(*prev_insn)))
> > > >                 return 0;
> > > >
> > > > -       if (*instruction != PPC_RAW_NOP()) {
> > > > +       /*
> > > > +        * For livepatch, the restore r2 instruction might have already been
> > > > +        * written previously, if the referenced symbol is in a previously
> > > > +        * unloaded module which is now being loaded again.  In that case, skip
> > > > +        * the warning and the instruction write.
> > > > +        */
> > > > +       if (insn_val == PPC_INST_LD_TOC)
> > > > +               return 0;
> > >
> > > Do we need "sym->st_shndx == SHN_LIVEPATCH" here?
> >
> > My original patch had that check, but I dropped it for simplicity.
> >
> > In the non-livepatch case, the condition should never be true, but it
> > doesn't hurt to check it anyway.
> 
> While this is the only place we use PPC_INST_LD_TOC, there is another
> place we use "PPC_RAW_STD(_R2, _R1, R2_STACK_OFFSET)", which
> is identical to PPC_INST_LD_TOC. So I am not quite sure whether this
> happens for non-livepatch.

It's not actually identical.  That's the "store r2 to the stack"
counterpart to the load in PPC_INST_LD_TOC, which loads r2 from the
stack.

For R_PPC_REL24 relocations, when calling a function which lives outside
the module, 24 bits isn't enough to encode the relative branch target
address.  So it has to save r2 (TOC pointer) to the stack, and branch to
a stub, which then branches to the external function.

When the external function returns execution to the instruction after
the original branch, that instruction needs to restore the TOC pointer
from the stack to r2.

The compiler knows this, and emits the instruction after the branch as a
NOP.  The module code replaces that NOP with a "restore r2 from the
stack".  That's what restore_r2() does.

Long story short, restore_r2() needs to ensure the instruction after the
branch restores r2 from the stack.  If that instruction is already
there, it doesn't need to do anything.

-- 
Josh

  reply	other threads:[~2023-01-25 18:53 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-25  3:38 [PATCH 0/2] powerpc: Fix livepatch module re-patching issue Josh Poimboeuf
2023-01-25  3:38 ` [PATCH 1/2] powerpc/module_64: Improve restore_r2() return semantics Josh Poimboeuf
2023-01-25  5:53   ` Song Liu
2023-01-25 13:24   ` Petr Mladek
2023-01-27 12:38   ` Miroslav Benes
2023-01-25  3:38 ` [PATCH 2/2] powerpc/module_64: Fix "expected nop" error on module re-patching Josh Poimboeuf
2023-01-25  6:09   ` Song Liu
2023-01-25 16:46     ` Josh Poimboeuf
2023-01-25 17:36       ` Song Liu
2023-01-25 18:53         ` Josh Poimboeuf [this message]
2023-01-25 18:58           ` Song Liu
2023-01-25 13:31   ` Petr Mladek
2023-01-27 12:50   ` Miroslav Benes
2023-01-27 13:48 ` [PATCH 0/2] powerpc: Fix livepatch module re-patching issue Joe Lawrence
2023-02-04 17:23 ` Josh Poimboeuf
2023-02-05  0:46   ` Michael Ellerman
2023-02-05 16:21     ` Josh Poimboeuf
2023-02-05  0:46 ` Michael Ellerman

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=20230125185316.ebvxecd7gsvgtudr@treble \
    --to=jpoimboe@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=live-patching@vger.kernel.org \
    --cc=npiggin@gmail.com \
    --cc=song@kernel.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