Patch "kvm: fix objtool relocation warning" has been added to the 5.14-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    kvm: fix objtool relocation warning

to the 5.14-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     kvm-fix-objtool-relocation-warning.patch
and it can be found in the queue-5.14 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit 06d12aec7037e70b028e11f9edbf7c5f6f2400e5
Author: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Date:   Sun Oct 3 13:34:19 2021 -0700

    kvm: fix objtool relocation warning
    
    [ Upstream commit 291073a566b2094c7192872cc0f17ce73d83cb76 ]
    
    The recent change to make objtool aware of more symbol relocation types
    (commit 24ff65257375: "objtool: Teach get_alt_entry() about more
    relocation types") also added another check, and resulted in this
    objtool warning when building kvm on x86:
    
        arch/x86/kvm/emulate.o: warning: objtool: __ex_table+0x4: don't know how to handle reloc symbol type: kvm_fastop_exception
    
    The reason seems to be that kvm_fastop_exception() is marked as a global
    symbol, which causes the relocation to ke kept around for objtool.  And
    at the same time, the kvm_fastop_exception definition (which is done as
    an inline asm statement) doesn't actually set the type of the global,
    which then makes objtool unhappy.
    
    The minimal fix is to just not mark kvm_fastop_exception as being a
    global symbol.  It's only used in that one compilation unit anyway, so
    it was always pointless.  That's how all the other local exception table
    labels are done.
    
    I'm not entirely happy about the kinds of games that the kvm code plays
    with doing its own exception handling, and the fact that it confused
    objtool is most definitely a symptom of the code being a bit too subtle
    and ad-hoc.  But at least this trivial one-liner makes objtool no longer
    upset about what is going on.
    
    Fixes: 24ff65257375 ("objtool: Teach get_alt_entry() about more relocation types")
    Link: https://lore.kernel.org/lkml/CAHk-=wiZwq-0LknKhXN4M+T8jbxn_2i9mcKpO+OaBSSq_Eh7tg@xxxxxxxxxxxxxx/
    Cc: Borislav Petkov <bp@xxxxxxx>
    Cc: Paolo Bonzini <pbonzini@xxxxxxxxxx>
    Cc: Sean Christopherson <seanjc@xxxxxxxxxx>
    Cc: Vitaly Kuznetsov <vkuznets@xxxxxxxxxx>
    Cc: Wanpeng Li <wanpengli@xxxxxxxxxxx>
    Cc: Jim Mattson <jmattson@xxxxxxxxxx>
    Cc: Joerg Roedel <joro@xxxxxxxxxx>
    Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
    Cc: Josh Poimboeuf <jpoimboe@xxxxxxxxxx>
    Cc: Nathan Chancellor <nathan@xxxxxxxxxx>
    Signed-off-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 2837110e66ed..50050d06672b 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -435,7 +435,6 @@ static int fastop(struct x86_emulate_ctxt *ctxt, fastop_t fop);
 	__FOP_RET(#op)
 
 asm(".pushsection .fixup, \"ax\"\n"
-    ".global kvm_fastop_exception \n"
     "kvm_fastop_exception: xor %esi, %esi; ret\n"
     ".popsection");
 



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux