Message ID | 2f6329ffd9674df6ff57e03edeb2ca54414770ab.1674617130.git.jpoimboe@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp77427wrn; Tue, 24 Jan 2023 19:47:57 -0800 (PST) X-Google-Smtp-Source: AMrXdXsAtMQVsHO7pYTP/SFdX+eGXeZbhsaxCh+lvxv3R3V/CnL09U0JaYq5KCxMTIFCk/rj2BAo X-Received: by 2002:a17:90b:1bc7:b0:22b:bbe3:672b with SMTP id oa7-20020a17090b1bc700b0022bbbe3672bmr16772244pjb.9.1674618477479; Tue, 24 Jan 2023 19:47:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674618477; cv=none; d=google.com; s=arc-20160816; b=NkCVBvANCoClGNv1SZqdazBRvk5CHQSTAK5cRgRkAcLMJt/FJFYxibUbecovxygK/V Aqp+m3+1XJ4tMYo6O6OdqoFBNxbu2x9TNiXDzAUvhMCOzSXy6+Dtc6UM1OJLr9d2TOs1 i0qzS0GVfAzzJmu4zb4p56F7QhDZ8PsFz+8iwPNC/jZNAkOYyGiyZj1PwmR8cVN9dM2N AC5nSRsRioEDQlCzySezAnj3SyEqCSP1AVkya4ZGBw6MoFx7irHIaUI/wMlmhR3lgyeP iy0OM5kAob7qEasa4PDUH6TMq9NvO1CicdKy+aub76hRiiRgoV9rrDQJR9HX5BhkIsjj 4N4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=k1bCbNUT9Y3VFPimjn1OvEYYDu3G+vfKH3M54CeWgWw=; b=PGs2FYthXgGmSUfRnEwwt12JlC7kuxyA/nmbSj9BGq2chOmAOD7dUnK3qW/OSNLxix U5OYAeJmYBEOuE59q/OFmzaZLN8ax+m+YiB6LcuqERh2YtavzV3uh0DbPG+sxYHNg/3j ERORn2ZdBoosmVmRFipKuzx6At/w23Ei/AgdtmSELxKEPK2MGzcDNv2NePKoCtGYbtPy n6nWn9f5JcMqamgmYx6Ig2aYd3RR3g4hUTM7KRcFhaFYXuZ2hIQELbFwew7yEM6O8YGU f23Z23OlxjDHGpd3pH8vzcYa2SYsw0Dc12xiksaqfg8bUEyN1zw/iLQIzHBBuIQIUsjb KmYQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=P9J1452o; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c18-20020a17090ab29200b00229c1a4a338si802772pjr.106.2023.01.24.19.47.44; Tue, 24 Jan 2023 19:47:57 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=P9J1452o; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232166AbjAYDiY (ORCPT <rfc822;rust.linux@gmail.com> + 99 others); Tue, 24 Jan 2023 22:38:24 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51558 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233279AbjAYDiW (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 24 Jan 2023 22:38:22 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7085CCA26; Tue, 24 Jan 2023 19:38:13 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id ED74D61444; Wed, 25 Jan 2023 03:38:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1A1AAC433A0; Wed, 25 Jan 2023 03:38:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1674617892; bh=7M3ieHPKjncgevNaIxm++BYHAAhc0S9LqYRA8tUI6Pc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=P9J1452odLsdx9doxYgTkxrLdCcOxbiWEcNN3c1SS4mdkU1oxRzvV4a4XV/0BbQ9l SBxFaspcH9MniyYLQbBXgGXc/40u0BVnlosMkZ59hGsQD2ZtlCSgjxkQ6YRqMLPlSZ PrGLsThlzNCrIgruY4wNOh2EKMnjXOqodtyk565vVkwRA9c3ZM9fgB+A5DldgqdSYt tQw6v6Rp0lqJA5umtMy0jcsmp3utJc6DJPUHg7Qip/IOYG6z7+TqLVowgk8ynnZS3N 8r+3N4ZEqgI0VoBXDnvPlvm6BvZES1t+sHzbRcI1WtgVfxlZ53ysJD7yxDpif/2MR6 Y9i+Oqrub8C7Q== From: Josh Poimboeuf <jpoimboe@kernel.org> To: Michael Ellerman <mpe@ellerman.id.au> Cc: live-patching@vger.kernel.org, Nicholas Piggin <npiggin@gmail.com>, Christophe Leroy <christophe.leroy@csgroup.eu>, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, Song Liu <song@kernel.org> Subject: [PATCH 2/2] powerpc/module_64: Fix "expected nop" error on module re-patching Date: Tue, 24 Jan 2023 19:38:05 -0800 Message-Id: <2f6329ffd9674df6ff57e03edeb2ca54414770ab.1674617130.git.jpoimboe@kernel.org> X-Mailer: git-send-email 2.39.0 In-Reply-To: <cover.1674617130.git.jpoimboe@kernel.org> References: <cover.1674617130.git.jpoimboe@kernel.org> MIME-Version: 1.0 Content-type: text/plain Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1755964744206022611?= X-GMAIL-MSGID: =?utf-8?q?1755964744206022611?= |
Series |
powerpc: Fix livepatch module re-patching issue
|
|
Commit Message
Josh Poimboeuf
Jan. 25, 2023, 3:38 a.m. UTC
When a module with a livepatched function is unloaded and then reloaded,
klp attempts to dynamically re-patch it. On ppc64, that fails with the
following error:
module_64: livepatch_nfsd: Expected nop after call, got e8410018 at e_show+0x60/0x548 [livepatch_nfsd]
livepatch: failed to initialize patch 'livepatch_nfsd' for module 'nfsd' (-8)
livepatch: patch 'livepatch_nfsd' failed for module 'nfsd', refusing to load module 'nfsd'
The error happens because the restore r2 instruction had already
previously been written into the klp module's replacement function when
the original function was patched the first time. So the instruction
wasn't a nop as expected.
When the restore r2 instruction has already been patched in, detect that
and skip the warning and the instruction write.
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
---
arch/powerpc/kernel/module_64.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
Comments
On Tue, Jan 24, 2023 at 7:38 PM Josh Poimboeuf <jpoimboe@kernel.org> wrote: > > When a module with a livepatched function is unloaded and then reloaded, > klp attempts to dynamically re-patch it. On ppc64, that fails with the > following error: > > module_64: livepatch_nfsd: Expected nop after call, got e8410018 at e_show+0x60/0x548 [livepatch_nfsd] > livepatch: failed to initialize patch 'livepatch_nfsd' for module 'nfsd' (-8) > livepatch: patch 'livepatch_nfsd' failed for module 'nfsd', refusing to load module 'nfsd' > > The error happens because the restore r2 instruction had already > previously been written into the klp module's replacement function when > the original function was patched the first time. So the instruction > wasn't a nop as expected. > > When the restore r2 instruction has already been patched in, detect that > and skip the warning and the instruction write. > > Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> > --- > arch/powerpc/kernel/module_64.c | 14 ++++++++++++-- > 1 file changed, 12 insertions(+), 2 deletions(-) > > diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c > index 016e79bba531..bf1da99fff74 100644 > --- a/arch/powerpc/kernel/module_64.c > +++ b/arch/powerpc/kernel/module_64.c > @@ -502,6 +502,7 @@ static unsigned long stub_for_addr(const Elf64_Shdr *sechdrs, > static int restore_r2(const char *name, u32 *instruction, struct module *me) > { > u32 *prev_insn = instruction - 1; > + u32 insn_val = *instruction; > > if (is_mprofile_ftrace_call(name)) > return 0; > @@ -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? Thanks, Song > + > + if (insn_val != PPC_RAW_NOP()) { > pr_err("%s: Expected nop after call, got %08x at %pS\n", > - me->name, *instruction, instruction); > + me->name, insn_val, instruction); > return -ENOEXEC; > } > > -- > 2.39.0 >
On Tue 2023-01-24 19:38:05, Josh Poimboeuf wrote: > When a module with a livepatched function is unloaded and then reloaded, > klp attempts to dynamically re-patch it. On ppc64, that fails with the > following error: > > module_64: livepatch_nfsd: Expected nop after call, got e8410018 at e_show+0x60/0x548 [livepatch_nfsd] > livepatch: failed to initialize patch 'livepatch_nfsd' for module 'nfsd' (-8) > livepatch: patch 'livepatch_nfsd' failed for module 'nfsd', refusing to load module 'nfsd' > > The error happens because the restore r2 instruction had already > previously been written into the klp module's replacement function when > the original function was patched the first time. So the instruction > wasn't a nop as expected. > > When the restore r2 instruction has already been patched in, detect that > and skip the warning and the instruction write. > > Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> It seems that the function does what it says. And it seems to be the only location where an instruction is checked before it is modified. I am fine with this approach. Reviewed-by: Petr Mladek <pmladek@suse.com> Best Regards, Petr
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.
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. Thanks, Song
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.
On Wed, Jan 25, 2023 at 10:53 AM Josh Poimboeuf <jpoimboe@kernel.org> wrote: > > 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. Ooops.. I misread the code. > > 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. Thanks for the explanation! Acked-by: Song Liu <song@kernel.org>
On Tue, 24 Jan 2023, Josh Poimboeuf wrote: > When a module with a livepatched function is unloaded and then reloaded, > klp attempts to dynamically re-patch it. On ppc64, that fails with the > following error: > > module_64: livepatch_nfsd: Expected nop after call, got e8410018 at e_show+0x60/0x548 [livepatch_nfsd] > livepatch: failed to initialize patch 'livepatch_nfsd' for module 'nfsd' (-8) > livepatch: patch 'livepatch_nfsd' failed for module 'nfsd', refusing to load module 'nfsd' > > The error happens because the restore r2 instruction had already > previously been written into the klp module's replacement function when > the original function was patched the first time. So the instruction > wasn't a nop as expected. > > When the restore r2 instruction has already been patched in, detect that > and skip the warning and the instruction write. > > Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Reviewed-by: Miroslav Benes <mbenes@suse.cz> M
diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c index 016e79bba531..bf1da99fff74 100644 --- a/arch/powerpc/kernel/module_64.c +++ b/arch/powerpc/kernel/module_64.c @@ -502,6 +502,7 @@ static unsigned long stub_for_addr(const Elf64_Shdr *sechdrs, static int restore_r2(const char *name, u32 *instruction, struct module *me) { u32 *prev_insn = instruction - 1; + u32 insn_val = *instruction; if (is_mprofile_ftrace_call(name)) return 0; @@ -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; + + if (insn_val != PPC_RAW_NOP()) { pr_err("%s: Expected nop after call, got %08x at %pS\n", - me->name, *instruction, instruction); + me->name, insn_val, instruction); return -ENOEXEC; }