Re: [RFC PATCH] Drop some asm from copy_user_64.S

[Ingo Molnar]

* Borislav Petkov <bp@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/