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 <kuleshovm...@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.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
