lkml.org 
[lkml]   [2020]   [Apr]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 8/8] x86/retpoline: Fix retpoline unwind
On Fri, Apr 24, 2020 at 02:30:28PM -0500, Josh Poimboeuf wrote:
> On Thu, Apr 23, 2020 at 02:47:25PM +0200, Peter Zijlstra wrote:
> > .macro CALL_NOSPEC reg:req
> > #ifdef CONFIG_RETPOLINE
> > - ANNOTATE_NOSPEC_ALTERNATIVE
> > - ALTERNATIVE_2 __stringify(ANNOTATE_RETPOLINE_SAFE; call *%\reg),\
> > - __stringify(RETPOLINE_CALL %\reg), X86_FEATURE_RETPOLINE,\
> > - __stringify(lfence; ANNOTATE_RETPOLINE_SAFE; call *%\reg), X86_FEATURE_RETPOLINE_AMD
> > + /*
> > + * This cannot be ALTERNATIVE_2 like with JMP_NOSPEC, because ORC
> > + * unwind data is alternative invariant and needs stack modifying
> > + * instructions to be in the same place for all alternatives.
> > + *
> > + * IOW the CALL instruction must be at the same offset for all cases.
> > + */
> > + ALTERNATIVE "", "lfence", X86_FEATURE_RETPOLINE_AMD
> > + ALTERNATIVE __stringify(ANNOTATE_RETPOLINE_SAFE; call *%\reg), \
> > + __stringify(call __x86_retpoline_\reg), X86_FEATURE_RETPOLINE
>
> I'm missing why ALTERNATIVE_2 wouldn't work here. How is the call a
> "stack modifying instruction"? It's not an intra-function call so it
> shouldn't affect ORC at all, right?

My bad. I find it hard not to consider CALL a stack modification. Let me
fix that.

\
 
 \ /
  Last update: 2020-04-28 20:57    [W:0.099 / U:1.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site