mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@suse.de>
To: Alexander Kuleshov <kuleshovmail@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86-64: no need to fix up physical addresses if they are correct
Date: Sat, 28 Feb 2015 14:48:32 +0100	[thread overview]
Message-ID: <20150228134832.GB11038@pd.tnic> (raw)
In-Reply-To: <1425130460-29807-1-git-send-email-kuleshovmail@gmail.com>

On Sat, Feb 28, 2015 at 07:34:20PM +0600, Alexander Kuleshov wrote:
> If kernel doesn't use kASLR and runned on the same address that was
> compiled to run, %rbp will be zero and no need to fix physical addresses
> in the page tables.
> 
> Signed-off-by: Alexander Kuleshov <kuleshovmail@gmail.com>
> ---
>  arch/x86/kernel/head_64.S | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
> index 6fd514d9..c0127bc 100644
> --- a/arch/x86/kernel/head_64.S
> +++ b/arch/x86/kernel/head_64.S
> @@ -86,6 +86,14 @@ startup_64:
>  	jnz	bad_address
>  
>  	/*
> +	 * We have no need to fixup the physical addresses in the page tables
> +	 * if there is no difference between the address where kernel compiled
> +	 * to run and the actual address where kernel running at.
> +	 */
> +	cmpq $0x0, %rbp
> +	je 1f

No thanks - this is saving 4 ADDs which probably execute even in
parallel on modern out-of-order x86, for the price of more code in asm
which people would have to spend mental energy on in the future without
any apparent gain.

If you really want to help out with kernel development, I'd suggest
you try fixing real bugs. You could read lkml and try to understand
and debug the issues people are reporting, get a box and start testing
linux-next every day and search the net for kernelnewbies (IRC channel
etc) for things to do.

Another great exercise is building randconfigs and trying to boot them
with kvm and see what splats happen - believe me, lots of them.

I sincerely hope that helps.

-- 
Regards/Gruss,
    Boris.

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

      reply	other threads:[~2015-02-28 13:49 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-28 13:34 Alexander Kuleshov
2015-02-28 13:48 ` 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=20150228134832.GB11038@pd.tnic \
    --to=bp@suse.de \
    --cc=hpa@zytor.com \
    --cc=kuleshovmail@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®