Re: [PATCH 03/11] objtool: Convert ANNOTATE_RETPOLINE_SAFE to ANNOTATE

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

 



On Fri, Sep 13, 2024 at 1:47 PM James Houghton <jthoughton@xxxxxxxxxx> wrote:
>
> On Wed, 6 Dec 2023, Sean Christopherson wrote:
> > On Mon, Dec 04, 2023, Peter Zijlstra wrote:
> > >
> > > --- a/arch/x86/include/asm/nospec-branch.h
> > > +++ b/arch/x86/include/asm/nospec-branch.h
> > > @@ -193,12 +193,7 @@
> > >   * objtool the subsequent indirect jump/call is vouched safe for retpoline
> > >   * builds.
> > >   */
> > > -.macro ANNOTATE_RETPOLINE_SAFE
> > > -.Lhere_\@:
> > > -   .pushsection .discard.retpoline_safe
> > > -   .long .Lhere_\@
> > > -   .popsection
> > > -.endm
> > > +#define ANNOTATE_RETPOLINE_SAFE    ANNOTATE type=ANNOTYPE_RETPOLINE_SAFE
> > >
> > >  /*
> > >   * (ab)use RETPOLINE_SAFE on RET to annotate away 'bare' RET instructions
> > > @@ -317,11 +312,7 @@
> > >
> > >  #else /* __ASSEMBLY__ */
> > >
> > > -#define ANNOTATE_RETPOLINE_SAFE                                    \
> > > -   "999:\n\t"                                              \
> > > -   ".pushsection .discard.retpoline_safe\n\t"              \
> > > -   ".long 999b\n\t"                                        \
> > > -   ".popsection\n\t"
> > > +#define ANNOTATE_RETPOLINE_SAFE ASM_ANNOTATE(ANNOTYPE_RETPOLINE_SAFE)
> >
> > This fails for some of my builds that end up with CONFIG_OBJTOOl=n.  Adding a
> > stub for ASM_ANNOTATE() gets me past that:
> >
> > @@ -156,6 +171,7 @@
> >  #define STACK_FRAME_NON_STANDARD(func)
> >  #define STACK_FRAME_NON_STANDARD_FP(func)
> >  #define ANNOTATE_NOENDBR
> > +#define ASM_ANNOTATE(x)
> >  #define ASM_REACHABLE
> >  #else
> >  #define ANNOTATE_INTRA_FUNCTION_CALL
> >
> > but then I run into other issues:
> >
> > arch/x86/kernel/relocate_kernel_32.S: Assembler messages:
> > arch/x86/kernel/relocate_kernel_32.S:96: Error: Parameter named `type' does not exist for macro `annotate'
> > arch/x86/kernel/relocate_kernel_32.S:166: Error: Parameter named `type' does not exist for macro `annotate'
> > arch/x86/kernel/relocate_kernel_32.S:174: Error: Parameter named `type' does not exist for macro `annotate'
> > arch/x86/kernel/relocate_kernel_32.S:200: Error: Parameter named `type' does not exist for macro `annotate'
> > arch/x86/kernel/relocate_kernel_32.S:220: Error: Parameter named `type' does not exist for macro `annotate'
> > arch/x86/kernel/relocate_kernel_32.S:285: Error: Parameter named `type' does not exist for macro `annotate'
>
> Sean pointed me at this series recently. It seems like these compile errors
> (and some others) go away with the following diff:
>
> diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-branch.h
> index 0bebdcad7ba1..036ab199859a 100644
> --- a/arch/x86/include/asm/nospec-branch.h
> +++ b/arch/x86/include/asm/nospec-branch.h
> @@ -489,7 +489,7 @@ static inline void call_depth_return_thunk(void) {}
>         "       .align 16\n"                                    \
>         "903:   lea    4(%%esp), %%esp;\n"                      \
>         "       pushl  %[thunk_target];\n"                      \
> -       "       ret;\n"                                         \
> +       "       ret;\n",                                        \
>         X86_FEATURE_RETPOLINE,                                  \
>         "lfence;\n"                                             \
>         ANNOTATE_RETPOLINE_SAFE                                 \
> diff --git a/include/linux/objtool.h b/include/linux/objtool.h
> index f6f80bfefe3b..e811b2ff3a9c 100644
> --- a/include/linux/objtool.h
> +++ b/include/linux/objtool.h
> @@ -159,6 +159,7 @@
>  #define STACK_FRAME_NON_STANDARD_FP(func)
>  #define ANNOTATE_NOENDBR
>  #define ASM_REACHABLE
> +#define ASM_ANNOTATE(x)
>  #else
>  #define ANNOTATE_INTRA_FUNCTION_CALL
>  .macro UNWIND_HINT type:req sp_reg=0 sp_offset=0 signal=0
> @@ -169,7 +170,7 @@
>  .endm
>  .macro REACHABLE
>  .endm
> -.macro ANNOTATE
> +.macro ANNOTATE type:req
>  .endm
>  #endif
>
> This series applies on top of the latest kvm-x86/next with only a few trivial
> conflicts, so I hope you are able to send a new version.
>
> I could send one for you, but I have no idea how to properly test it.

Hi Peter,

I'll go ahead and repost this series soon unless you tell me otherwise. :)





[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux