On Fri, Feb 22, 2019 at 03:55:25PM -0800, Andy Lutomirski wrote:
> On Fri, Feb 22, 2019 at 2:26 PM Peter Zijlstra <pet...@infradead.org> wrote:
> > arch/x86/entry/entry_64.o: warning: objtool: .altinstr_replacement+0xb1:
> > redundant CLAC
>
> Does objtool understand altinstr?
Yep, otherwise it would've never found any of the STAC/CLAC instructions
to begin with, they're all alternatives. The emitted code is all NOPs.
> If it understands that this is an
> altinstr associated with a not-actually-a-fuction (i.e. END not
> ENDPROC) piece of code, it could suppress this warning.
Using readelf on entry_64.o the symbol type appears to be STT_NOTYPE for
these 'functions', so yes, I can try and ignore this warning for those.
> > +#define AC_SAFE(func) \
> > + static void __used __section(.discard.ac_safe) \
> > + *__func_ac_safe_##func = func
>
> Are we okay with annotating function *declarations* in a way that
> their addresses get taken whenever the declaration is processed? It
> would be nice if we could avoid this.
>
> I'm wondering if we can just change the code that does getreg() and
> load_gs_index() so it doesn't do it with AC set. Also, what about
> paravirt kernels? They'll call into PV code for load_gs_index() with
> AC set.
Fixing that code would be fine; but we need that annotation regardless,
read Linus' email a little further back, he wants things like
copy_{to,from}_user_unsafe().
Those really would need to be marked AC-safe, there's no inlining that.
That said, yes these annotations _suck_. But it's what we had and works,
I'm just copying it (from STACK_FRAME_NON_STANDARD).
That said; maybe we can do something like:
#define AC_SAFE(func) \
asm (".pushsection .discard.ac_safe_sym\n\t" \
"999: .ascii \"" #func "\"\n\t" \
".popsection\n\t" \
".pushsection .discard.ac_safe\n\t" \
_ASM_PTR " 999b\n\t" \
".popsection")
I just don't have a clue on how to read that in objtool; weak elf foo.
I'll see if I can make it work.
