Date:   Fri, 3 Mar 2017 20:52:13 +0800
From:   Baoquan He <bhe@...hat.com>
To:     Borislav Petkov <bp@...e.de>
Cc:     tglx@...utronix.de, hpa@...or.com, mingo@...hat.com,
        linux-kernel@...r.kernel.org, x86@...nel.org,
        keescook@...omium.org, yinghai@...nel.org, anderson@...hat.com,
        luto@...nel.org, thgarnie@...gle.com, kuleshovmail@...il.com
Subject: Re: [PATCH v4 1/3] x86: Introduce a new constant KERNEL_MAPPING_SIZE

On 03/03/17 at 01:16pm, Borislav Petkov wrote:
> On Fri, Mar 03, 2017 at 08:06:16PM +0800, Baoquan He wrote:
> > OK, I am trying to make things clearer, seems I failed. I thought kernel
> > iamge size is only allowed to be 512M at most, but can be mapped into 1G
> > region.
> 
> It doesn't look like it. But we could be missing something. You could
> try some git archeology to find out why the 512M limit. It could be "no
> reason", it could be remnant from 32-bit, it could be anything...
> 
> There's the full git history here too:
> 
> https://git.kernel.org/cgit/linux/kernel/git/history/history.git
> 
> in case it helps.

Thanks, have got all related change history below. In the last commit log
Ingo wrote he was just trying to give more space to kernel and push
modules up a bit, and it should be enough for a few years. My thought of
introducing KERNEL_MAPPING_SIZE is mainly because in commit 85eb69a1
("x86: increase the kernel text limit to 512 MB") Ingo is trying to
increase kernel image size, since the really large static arrays and
building allyesconfig kernel are all bloating kernel image. I feel Ingo
is very careful to keep the pace to increase it, guess people don't want
to see kernel image can be made by default as 1G big at one time without
obvious reason. AFAIK, peopel sometime have to tell how much space it
will increae with their new feature or big change. This is a very good
self alert with a limited but usually enough value, 512M, let people pay
attention to the elegacy but not always many lines of code, think more
and refector code. And linker script is the guard to check it. 

Not sure if I make myself clear. I hesitated to do that earlier, so
finally introduce KERNEL_MAPPING_SIZE. Surely in the current case, as
you said, 1G is hard-constrainted line, unless we decide to give a
larger space for kernel mapping or put it other place since Intel people
have been working on 5-level page mapping thing, we don't lack virtual
space, but kernel mapping is too constrainted. Even though we have more
than 1G kernel mapping space, image size still should be limited to a
small value, like plus 128M or + 256M.

***
commit 85eb69a16aab5a394ce043c2131319eae35e6493
Author: Ingo Molnar <mingo@...e.hu>
Date:   Thu Feb 21 12:50:51 2008 +0100

    x86: increase the kernel text limit to 512 MB
    
    people sometimes do crazy stuff like building really large static
    arrays into their kernels or building allyesconfig kernels. Give
    more space to the kernel and push modules up a bit: kernel has
    512 MB and modules have 1.5 GB.
    
    Should be enough for a few years ;-)

***
d4afe414    x86: rename KERNEL_TEXT_SIZE => KERNEL_IMAGE_SIZE
Rename it to be KERNEL_IMAGE_SIZE

***
88f3aec7    x86: fix spontaneous reboot with allyesconfig bzImage
In this commit Ingo changed KERNEL_TEXT_SIZE from 40M to 128M.

> 
> > It's fine to me, thing can be solved anyway. Will repost with
> > KERNEL_IMAGE_SIZE by default 1G.
> 
> I think you should slow down first and try to find out why the 512
> default. Then we can talk about changes.
> 
> -- 
> Regards/Gruss,
>     Boris.
> 
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
> -- 

Powered by blists - more mailing lists