All of lore.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Ingo Molnar <mingo@kernel.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andy Lutomirski <luto@amacapital.net>,
	Denys Vlasenko <dvlasenk@redhat.com>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] Drop some asm from copy_user_64.S
Date: Wed, 13 May 2015 12:28:32 +0200	[thread overview]
Message-ID: <20150513102832.GE1517@pd.tnic> (raw)
In-Reply-To: <20150513061954.GA24538@gmail.com>

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 */
ENTRY(_copy_to_user)
	CFI_STARTPROC
	GET_THREAD_INFO(%rax)
	movq %rdi,%rcx
	addq %rdx,%rcx
	jc bad_to_user
	cmpq TI_addr_limit(%rax),%rcx
	ja bad_to_user

This is adding @to (in %rdi) with size (in %rdx) and then looking at the
carry flag. __chk_range_not_ok() does the same thing, but with a single
operation, AFAICT:

static inline bool __chk_range_not_ok(unsigned long addr, unsigned long size, unsigned long limit)
{
        /*
         * If we have used "sizeof()" for the size,
         * we know it won't overflow the limit (but
         * it might overflow the 'addr', so it's
         * important to subtract the size from the
         * limit, not add it to the address).
         */
        if (__builtin_constant_p(size))
                return addr > limit - size;

and we're avoiding the addr overflow by subtracting size from limit.

So the resulting asm looks like this:

        .file 22 "./arch/x86/include/asm/uaccess.h"
        .loc 22 54 0
        movq    -16360(%r14), %rax      # _208->addr_limit.seg, tmp347		%r14 contains thread_info
        subq    $88, %rax       #, D.37904					88 is the size

        .file 23 "./arch/x86/include/asm/uaccess_64.h"
        .loc 23 165 0
        cmpq    %rax, %r12      # D.37904, ubuf					%r12 contains the user ptr
        ja      .L493   #,
        movq    %r12, %rdi      # ubuf, to					prep args for copy_user...
        movl    $88, %edx       #, len

										alternative starts here
	#APP
	# 36 "./arch/x86/include/asm/uaccess_64.h" 1
	661:
	call copy_user_generic_unrolled	#
	....


so we end up replacing

	MOV
	ADD
	JC
	CMP
	JA
	JMP (alternative)

with

	MOV
	SUB
	CMP
	JA
	MOV
	MOV
	CALL (alternative)

The only problem I see here is that we have to do two MOVs to put args
in proper registers before calling the copy_user* version. But we end
up with a single conditional instead of two. And the MOVs are cheaper.
Also, we gets rid of asm glue, even betterer :-)

> I'd keep any changes to inlining decisions a separate patch and do
> vmlinux before/after size analysis as well, so that we don't mix the
> effects of the various enhancements.

Yap.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

      reply	other threads:[~2015-05-13 10:28 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-12 20:57 [RFC PATCH] Drop some asm from copy_user_64.S Borislav Petkov
2015-05-12 21:13 ` Linus Torvalds
2015-05-12 21:53   ` Borislav Petkov
2015-05-13  9:52     ` Borislav Petkov
2015-05-13 10:31       ` Ingo Molnar
2015-05-13 10:43         ` Borislav Petkov
2015-05-13 10:46           ` Ingo Molnar
2015-05-13 11:16             ` Borislav Petkov
2015-05-13 16:02       ` Linus Torvalds
2015-05-14  9:36         ` Borislav Petkov
2015-05-13  6:19 ` Ingo Molnar
2015-05-13 10:28   ` Borislav Petkov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150513102832.GE1517@pd.tnic \
    --to=bp@alien8.de \
    --cc=dvlasenk@redhat.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mingo@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.