On Wed, May 13, 2015 at 09:02:41AM -0700, Linus Torvalds wrote:
> The nice thing about using "rep movsb" for the user copy is that not
> only is it fairly close to optimal (for non-constant sizes) on newer
> Intel CPU's, but the fixup is also trivial. So we really should inline
> it. Just look at i
On Wed, May 13, 2015 at 2:52 AM, Borislav Petkov wrote:
>
> 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
On Wed, May 13, 2015 at 12:46:30PM +0200, Ingo Molnar wrote:
>
> * Borislav Petkov wrote:
>
> > On Wed, May 13, 2015 at 12:31:40PM +0200, Ingo Molnar wrote:
> > > So why should an alternatives-CALL, inlined directly into call sites,
> > > cost more kernel space?
> >
> > Not the alternatives CAL
* Borislav Petkov wrote:
> On Wed, May 13, 2015 at 12:31:40PM +0200, Ingo Molnar wrote:
> > So why should an alternatives-CALL, inlined directly into call sites,
> > cost more kernel space?
>
> Not the alternatives CALL alone but inlining _copy_*_user with all
> the preparation glue around it
On Wed, May 13, 2015 at 12:31:40PM +0200, Ingo Molnar wrote:
> So why should an alternatives-CALL, inlined directly into call sites,
> cost more kernel space?
Not the alternatives CALL alone but inlining _copy_*_user with all the
preparation glue around it would. Basically what we're doing current
* Borislav Petkov 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:
On Wed, May 13, 2015 at 08:19:55AM +0200, Ingo Molnar wrote:
> Looks nice. Would be useful to do before/after analysis of the
> generated asm with a defconfig and document that in the changelog.
Right, so I'm looking at what we have now:
/* Standard copy_to_user with segment limit checking */
ENT
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:
textdata bss
* Borislav Petkov wrote:
> Hi guys,
>
> this is just an RFC first to sanity-check what I'm trying to do:
>
> I want to get rid of the asm glue in arch/x86/lib/copy_user_64.S which
> prepares the copy_user* alternatives calls. And replace it with nice and
> clean C.
>
> The other intention is
On Tue, May 12, 2015 at 02:13:33PM -0700, Linus Torvalds wrote:
> On Tue, May 12, 2015 at 1:57 PM, Borislav Petkov wrote:
> >
> > I want to get rid of the asm glue in arch/x86/lib/copy_user_64.S which
> > prepares the copy_user* alternatives calls. And replace it with nice and
> > clean C.
>
> Ac
On Tue, May 12, 2015 at 1:57 PM, Borislav Petkov wrote:
>
> I want to get rid of the asm glue in arch/x86/lib/copy_user_64.S which
> prepares the copy_user* alternatives calls. And replace it with nice and
> clean C.
Ack. I'm not a fan of the x86-64 usercopy funmctions.
That said, I think you sh
Hi guys,
this is just an RFC first to sanity-check what I'm trying to do:
I want to get rid of the asm glue in arch/x86/lib/copy_user_64.S which
prepares the copy_user* alternatives calls. And replace it with nice and
clean C.
The other intention is to switch to using copy_user_generic() which d
12 matches
Mail list logo
