Message ID | 20230222162511.7964-1-rdunlap@infradead.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp676850wrd; Wed, 22 Feb 2023 08:37:34 -0800 (PST) X-Google-Smtp-Source: AK7set8osNTBErikFv81pR1VNDg7JPZpcVMmp1b4Y82LCFOpNX1rMCwpES5bPAtpScyjlN9cLHDw X-Received: by 2002:a05:6402:3810:b0:4ab:4410:ae1a with SMTP id es16-20020a056402381000b004ab4410ae1amr9884038edb.15.1677083853791; Wed, 22 Feb 2023 08:37:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1677083853; cv=none; d=google.com; s=arc-20160816; b=zVr3lMMSaAgqsYEaMaIiAXyRtfq/nk+RlithHf9daEtMyhXt6z1zJor74STQBAdoYg HYgWBIRPcuWa4kq3cQF0tjEMzWNpNPK67InNY465Tq8os1KjCoLUhR+fqQauowROFkri uS/KEx5URv6GQ62DarCpwJAcBQn8jOtXqqtpwlM7tMK7Xjzro9HbesFQdkoqeOYdruBf Q5IZNAmROUan6gTfqRPhuJyygQ+v7wxzu66JuWN+2HYVTJcrpOAErSwPQrO63tBDKHXr 3yLBg45epT3GdURrwvRnqGGw0UHKS70+BfyrDE/cHbupKjg9xU7a18/TSt3WApvw+C9d dPHQ== 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 :message-id:date:subject:cc:to:from:dkim-signature; bh=f/C40n0VnfpsaAjpBUUoqqPRbz2Z1ljnsPOpLaHJNqA=; b=anx8UX9KE1BKue+m6fm4bz8OCGeB8z87uSKp++aHvavjxLgFW+GxaNgy/EAazii+3x IOqWrlIYiAB2Y/LK2oqr5EfJiahmCrUqOqn3baY9Nut+vU2ADMaD2MJmFBy6re25y9US kk2b2ngZK2xsbZM0qpO1CgXddDE5fW2MjylvWbso9EfVs1c1c46C2QewGzppcaOgwkbg Lltf15smbEXaU38f5zq9g2QXWcbdmkoXFxxetFkKjPXi9N2AP6i15fUrGlMh2/ZvL4Ju ojAWKchz33yeZBJvveVnJvAC9Prz7D5MGEDXeCtsAobpzdFKFFp3d0XTna1x2h3P0bMG GNRA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=bombadil.20210309 header.b=fZxF1R8E; 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 Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v28-20020a17090651dc00b008d0378ec19fsi13858062ejk.650.2023.02.22.08.37.10; Wed, 22 Feb 2023 08:37:33 -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=@infradead.org header.s=bombadil.20210309 header.b=fZxF1R8E; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231494AbjBVQZS (ORCPT <rfc822;chinmaygameti@gmail.com> + 99 others); Wed, 22 Feb 2023 11:25:18 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45434 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231994AbjBVQZQ (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 22 Feb 2023 11:25:16 -0500 Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:3::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5C4D43754D; Wed, 22 Feb 2023 08:25:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Transfer-Encoding: MIME-Version:Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:Content-Type: Content-ID:Content-Description:In-Reply-To:References; bh=f/C40n0VnfpsaAjpBUUoqqPRbz2Z1ljnsPOpLaHJNqA=; b=fZxF1R8ELJ8fMvsoc8opm6QNtf xG8Duc0mqPb3Ke4PeNolZv8GuJetxUJnaC41j1wp3f3FWBdiEC2FdfDdst/udqGun7+Bfu23DUasR vWRYBut0O/uKrZXZIBC5mo14kEuIKVIdqPqP3K+gsHcjUN4XT178YqsSaoMHBsUI84/hK6fZFPyri +1A9i8L4dxYFxIN95UIQ5TZh7YXBYNmPDd7xCmsN9nFAKBcQanUN5dOKj1PQueXD5vy/zppfccI28 iatbAY4PsQgwoyJk6cIOF1GmClntWnVtG2mz4TFDatLSixsdzZwfMUu//GUn/nQA0aRjJgL03dcWo hWVnNpEw==; Received: from [2601:1c2:980:9ec0::df2f] (helo=bombadil.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1pUrvc-00D15y-RA; Wed, 22 Feb 2023 16:25:12 +0000 From: Randy Dunlap <rdunlap@infradead.org> To: linux-kernel@vger.kernel.org Cc: Randy Dunlap <rdunlap@infradead.org>, Vineeth Pillai <viremana@linux.microsoft.com>, Paolo Bonzini <pbonzini@redhat.com>, Vitaly Kuznetsov <vkuznets@redhat.com>, Sean Christopherson <seanjc@google.com>, kvm@vger.kernel.org Subject: [PATCH v2] KVM: SVM: hyper-v: placate modpost section mismatch error Date: Wed, 22 Feb 2023 08:25:11 -0800 Message-Id: <20230222162511.7964-1-rdunlap@infradead.org> X-Mailer: git-send-email 2.39.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE 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?1758516145904583012?= X-GMAIL-MSGID: =?utf-8?q?1758549878672689548?= |
Series |
[v2] KVM: SVM: hyper-v: placate modpost section mismatch error
|
|
Commit Message
Randy Dunlap
Feb. 22, 2023, 4:25 p.m. UTC
modpost reports section mismatch errors/warnings:
WARNING: modpost: vmlinux.o: section mismatch in reference: svm_hv_hardware_setup (section: .text) -> (unknown) (section: .init.data)
WARNING: modpost: vmlinux.o: section mismatch in reference: svm_hv_hardware_setup (section: .text) -> (unknown) (section: .init.data)
WARNING: modpost: vmlinux.o: section mismatch in reference: svm_hv_hardware_setup (section: .text) -> (unknown) (section: .init.data)
Marking svm_hv_hardware_setup() as __init fixes the warnings.
I don't know why this should be needed -- it seems like a compiler
problem to me since the calling function is marked as __init.
This "(unknown) (section: .init.data)" all refer to svm_x86_ops.
Fixes: 1e0c7d40758b ("KVM: SVM: hyper-v: Remote TLB flush for SVM")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Vineeth Pillai <viremana@linux.microsoft.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: Sean Christopherson <seanjc@google.com>
Cc: kvm@vger.kernel.org
---
v2: also make the empty stub function be __init (Vitaly)
arch/x86/kvm/svm/svm_onhyperv.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Comments
On Wed, Feb 22, 2023, Randy Dunlap wrote: > modpost reports section mismatch errors/warnings: > WARNING: modpost: vmlinux.o: section mismatch in reference: svm_hv_hardware_setup (section: .text) -> (unknown) (section: .init.data) > WARNING: modpost: vmlinux.o: section mismatch in reference: svm_hv_hardware_setup (section: .text) -> (unknown) (section: .init.data) > WARNING: modpost: vmlinux.o: section mismatch in reference: svm_hv_hardware_setup (section: .text) -> (unknown) (section: .init.data) > > Marking svm_hv_hardware_setup() as __init fixes the warnings. > > I don't know why this should be needed -- it seems like a compiler > problem to me since the calling function is marked as __init. It's not a compiler issue. __initdata is freed after init and so must not be accessed by __init-less functions. This as a changelog? Tag svm_hv_hardware_setup() with __init to fix a modpost warning as the non-stub implementation accesses __initdata (svm_x86_ops), i.e. would generate a use-after-free if svm_hv_hardware_setup() were actually invoked post-init. The helper is only called from svm_hardware_setup(), which is also __init, i.e. other than the modpost warning, lack of __init is benign. With that (in case Paolo grabs this directly): Reviewed-by: Sean Christopherson <seanjc@google.com> > This "(unknown) (section: .init.data)" all refer to svm_x86_ops. > > Fixes: 1e0c7d40758b ("KVM: SVM: hyper-v: Remote TLB flush for SVM") > Signed-off-by: Randy Dunlap <rdunlap@infradead.org> > Cc: Vineeth Pillai <viremana@linux.microsoft.com> > Cc: Paolo Bonzini <pbonzini@redhat.com> > Cc: Vitaly Kuznetsov <vkuznets@redhat.com> > Cc: Sean Christopherson <seanjc@google.com> > Cc: kvm@vger.kernel.org > --- > v2: also make the empty stub function be __init (Vitaly) > > arch/x86/kvm/svm/svm_onhyperv.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff -- a/arch/x86/kvm/svm/svm_onhyperv.h b/arch/x86/kvm/svm/svm_onhyperv.h > --- a/arch/x86/kvm/svm/svm_onhyperv.h > +++ b/arch/x86/kvm/svm/svm_onhyperv.h > @@ -30,7 +30,7 @@ static inline void svm_hv_init_vmcb(stru > hve->hv_enlightenments_control.msr_bitmap = 1; > } > > -static inline void svm_hv_hardware_setup(void) > +static inline __init void svm_hv_hardware_setup(void) > { > if (npt_enabled && > ms_hyperv.nested_features & HV_X64_NESTED_ENLIGHTENED_TLB) { > @@ -84,7 +84,7 @@ static inline void svm_hv_init_vmcb(stru > { > } > > -static inline void svm_hv_hardware_setup(void) > +static inline __init void svm_hv_hardware_setup(void) > { > } > >
Randy Dunlap <rdunlap@infradead.org> writes: > modpost reports section mismatch errors/warnings: > WARNING: modpost: vmlinux.o: section mismatch in reference: svm_hv_hardware_setup (section: .text) -> (unknown) (section: .init.data) > WARNING: modpost: vmlinux.o: section mismatch in reference: svm_hv_hardware_setup (section: .text) -> (unknown) (section: .init.data) > WARNING: modpost: vmlinux.o: section mismatch in reference: svm_hv_hardware_setup (section: .text) -> (unknown) (section: .init.data) > > Marking svm_hv_hardware_setup() as __init fixes the warnings. > > I don't know why this should be needed -- it seems like a compiler > problem to me since the calling function is marked as __init. > > This "(unknown) (section: .init.data)" all refer to svm_x86_ops. > > Fixes: 1e0c7d40758b ("KVM: SVM: hyper-v: Remote TLB flush for SVM") > Signed-off-by: Randy Dunlap <rdunlap@infradead.org> > Cc: Vineeth Pillai <viremana@linux.microsoft.com> > Cc: Paolo Bonzini <pbonzini@redhat.com> > Cc: Vitaly Kuznetsov <vkuznets@redhat.com> > Cc: Sean Christopherson <seanjc@google.com> > Cc: kvm@vger.kernel.org > --- > v2: also make the empty stub function be __init (Vitaly) Thanks! Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com> > > arch/x86/kvm/svm/svm_onhyperv.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff -- a/arch/x86/kvm/svm/svm_onhyperv.h b/arch/x86/kvm/svm/svm_onhyperv.h > --- a/arch/x86/kvm/svm/svm_onhyperv.h > +++ b/arch/x86/kvm/svm/svm_onhyperv.h > @@ -30,7 +30,7 @@ static inline void svm_hv_init_vmcb(stru > hve->hv_enlightenments_control.msr_bitmap = 1; > } > > -static inline void svm_hv_hardware_setup(void) > +static inline __init void svm_hv_hardware_setup(void) > { > if (npt_enabled && > ms_hyperv.nested_features & HV_X64_NESTED_ENLIGHTENED_TLB) { > @@ -84,7 +84,7 @@ static inline void svm_hv_init_vmcb(stru > { > } > > -static inline void svm_hv_hardware_setup(void) > +static inline __init void svm_hv_hardware_setup(void) > { > } > >
On 2/22/23 17:46, Sean Christopherson wrote: > Tag svm_hv_hardware_setup() with __init to fix a modpost warning as the > non-stub implementation accesses __initdata (svm_x86_ops), i.e. would > generate a use-after-free if svm_hv_hardware_setup() were actually invoked > post-init. The helper is only called from svm_hardware_setup(), which is > also __init, i.e. other than the modpost warning, lack of __init is benign. Done. It's caused by the compiler deciding not to inline the function, probably. Also Cc'ed stable. Paolo
On Wed, 22 Feb 2023 19:32:53 +0100 Paolo Bonzini <pbonzini@redhat.com> wrote: Maybe we can use __always_inline? I just noticed this thread today by chance. https://lore.kernel.org/all/20210624095147.880513802@infradead.org/ > On 2/22/23 17:46, Sean Christopherson wrote: > > Tag svm_hv_hardware_setup() with __init to fix a modpost warning as the > > non-stub implementation accesses __initdata (svm_x86_ops), i.e. would > > generate a use-after-free if svm_hv_hardware_setup() were actually invoked > > post-init. The helper is only called from svm_hardware_setup(), which is > > also __init, i.e. other than the modpost warning, lack of __init is benign. > > Done. It's caused by the compiler deciding not to inline the function, > probably. > > Also Cc'ed stable. > > Paolo >
On Thu, Feb 23, 2023, Zhi Wang wrote: > On Wed, 22 Feb 2023 19:32:53 +0100 > Paolo Bonzini <pbonzini@redhat.com> wrote: > > Maybe we can use __always_inline? I just noticed this thread today by chance. Using __always_inline will "fix" the problem, but it's not necessary in this case, and in some ways it's less correct. The noinstr case you linked is different because the helpers in question can (and are) be used in noinstr and regular sections, i.e. shouldn't be tagged noinstr. In this case, svm_hv_hardware_setup() must be called from __init functions, i.e. doesn't need to be unopinionated. And FWIW, svm_hv_hardware_setup() really doesn't need to be inlined. > https://lore.kernel.org/all/20210624095147.880513802@infradead.org/ > > > On 2/22/23 17:46, Sean Christopherson wrote: > > > Tag svm_hv_hardware_setup() with __init to fix a modpost warning as the > > > non-stub implementation accesses __initdata (svm_x86_ops), i.e. would > > > generate a use-after-free if svm_hv_hardware_setup() were actually invoked > > > post-init. The helper is only called from svm_hardware_setup(), which is > > > also __init, i.e. other than the modpost warning, lack of __init is benign. > > > > Done. It's caused by the compiler deciding not to inline the function, > > probably. > > > > Also Cc'ed stable. > > > > Paolo > > >
diff -- a/arch/x86/kvm/svm/svm_onhyperv.h b/arch/x86/kvm/svm/svm_onhyperv.h --- a/arch/x86/kvm/svm/svm_onhyperv.h +++ b/arch/x86/kvm/svm/svm_onhyperv.h @@ -30,7 +30,7 @@ static inline void svm_hv_init_vmcb(stru hve->hv_enlightenments_control.msr_bitmap = 1; } -static inline void svm_hv_hardware_setup(void) +static inline __init void svm_hv_hardware_setup(void) { if (npt_enabled && ms_hyperv.nested_features & HV_X64_NESTED_ENLIGHTENED_TLB) { @@ -84,7 +84,7 @@ static inline void svm_hv_init_vmcb(stru { } -static inline void svm_hv_hardware_setup(void) +static inline __init void svm_hv_hardware_setup(void) { }