lkml.org 
[lkml]   [2015]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH] Drop some asm from copy_user_64.S

* Borislav Petkov <bp@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


\
 
 \ /
  Last update: 2015-05-13 12:41    [W:0.911 / U:0.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site