* Borislav Petkov <b...@alien8.de> wrote:
> On Tue, May 12, 2015 at 11:53:20PM +0200, Borislav Petkov wrote:
> > > That said, I think you should uninline those things, and move them
> > > from a header file to a C file (arch/x86/lib/uaccess.c?).
>
> It is starting to look better wrt size:
>
> x86_64_defconfig:
>
> text data bss dec hex filename
> before: 12375798 1812800 1085440 15274038 e91036 vmlinux
> after: 12269658 1812800 1085440 15167898 e7719a
> vmlinux
>
> Now we CALL _copy_*_user which does CALL the optimal alternative
> version. Advantage is that we're saving some space and alternatives
> application for copy_user* is being done in less places, i.e.
> arch/x86/lib/uaccess_64.c. If I move all copy_user_generic() callers
> there, it would be the only compilation unit where the alternatives
> will be done.
>
> The disadvantage is that we have CALL after CALL and I wanted to
> have a single CALL directly to the optimal copy_user function.
> That'll cost us space, though, and more alternatives sites to patch
> during boot...
>
> Thoughts?
So why should an alternatives-CALL, inlined directly into call sites,
cost more kernel space?
It should only be some more metadata, but that's outside any hot path
and would be freed on init. The actual hot instructions should be
exactly the same as a regular call, minus the double CALL indirection.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
