Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1591898 > unrolled thread

Re: [PATCH v4 1/3] x86: Introduce a new constant KERNEL_MAPPING_SIZE

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v4 1/3] x86: Introduce a new constant KERNEL_MAPPING_SIZE Baoquan He <bhe@redhat.com> - 2017-03-03 13:10 +0100
    Re: [PATCH v4 1/3] x86: Introduce a new constant KERNEL_MAPPING_SIZE Baoquan He <bhe@redhat.com> - 2017-03-03 14:30 +0100
      Re: [PATCH v4 1/3] x86: Introduce a new constant KERNEL_MAPPING_SIZE Borislav Petkov <bp@suse.de> - 2017-03-03 15:30 +0100
        Re: [PATCH v4 1/3] x86: Introduce a new constant KERNEL_MAPPING_SIZE Baoquan He <bhe@redhat.com> - 2017-03-03 16:10 +0100
          Re: [PATCH v4 1/3] x86: Introduce a new constant KERNEL_MAPPING_SIZE Borislav Petkov <bp@suse.de> - 2017-03-03 19:30 +0100
            Re: [PATCH v4 1/3] x86: Introduce a new constant KERNEL_MAPPING_SIZE Baoquan He <bhe@redhat.com> - 2017-03-04 11:20 +0100
              Re: [PATCH v4 1/3] x86: Introduce a new constant KERNEL_MAPPING_SIZE Borislav Petkov <bp@suse.de> - 2017-03-04 13:00 +0100
                Re: [PATCH v4 1/3] x86: Introduce a new constant KERNEL_MAPPING_SIZE Baoquan He <bhe@redhat.com> - 2017-03-04 15:00 +0100
        Re: [PATCH v4 1/3] x86: Introduce a new constant KERNEL_MAPPING_SIZE Baoquan He <bhe@redhat.com> - 2017-03-03 16:10 +0100
    Re: [PATCH v4 1/3] x86: Introduce a new constant KERNEL_MAPPING_SIZE Baoquan He <bhe@redhat.com> - 2017-03-03 16:30 +0100
    Re: [PATCH v4 1/3] x86: Introduce a new constant KERNEL_MAPPING_SIZE Borislav Petkov <bp@suse.de> - 2017-03-03 17:00 +0100

#1591898 — Re: [PATCH v4 1/3] x86: Introduce a new constant KERNEL_MAPPING_SIZE

On 03/03/17 at 12:43pm, Borislav Petkov wrote:
> On Sun, Feb 26, 2017 at 12:09:08PM +0800, Baoquan He wrote:
> > Am I right on understanding it?
> 
> That's exactly what I mean: KERNEL_IMAGE_SIZE is 512M by default but
> we're not hard-constrained to it - we're hard-constrained to a 1G limit
> as this is the 1G which is covered by level2_kernel_pgt.
> 
> And in thinking about this more, I know I suggested making the
> KERNEL_IMAGE_SIZE by default 1G in order to simplify things.
> 
> But you're adding another KERNEL_MAPPING_SIZE which confuses things
> more. And I fail to see why we absolutely need it.

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.
> 
> So we suggest kernel image size should be 512M but then we still will
> be using a whole 1G mapping for it anyway and a whole page of PMDs at
> level2_kernel_pgt.
> 
> So why even bother?
> 
> Just make it 1G and don't introduce anything new.

It's fine to me, thing can be solved anyway. Will repost with
KERNEL_IMAGE_SIZE by default 1G.

Thanks
Baoquan

[toc] | [next] | [standalone]

#1591936

On 03/03/17 at 08:52pm, Baoquan He wrote:
> 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.
> 

And another meaning of defining kernel iamge size and mapping size
differently is we can randomize the limited kernel image in the mapping
area. If they are the same or kernel image can be very large, the
position will be fixed or very few, kernel text KASLR will be
meaningless. E.g 512M of kernel image, 16M aligned, there are 32 slots
we can choose to position. If kernel image can be 1g either, no
possibility to randomize at all.

> 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@elte.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)
> > -- 

[toc] | [prev] | [next] | [standalone]

#1591985

On Fri, Mar 03, 2017 at 09:11:52PM +0800, Baoquan He wrote:
> And another meaning of defining kernel iamge size and mapping size
> differently is we can randomize the limited kernel image in the mapping
> area. If they are the same or kernel image can be very large, the
> position will be fixed or very few, kernel text KASLR will be
> meaningless.

This is simply not true:

@@ -408,9 +408,9 @@ static unsigned long find_random_virt_addr(unsigned long minimum,
        /*
         * There are how many CONFIG_PHYSICAL_ALIGN-sized slots
         * that can hold image_size within the range of minimum to
-        * KERNEL_IMAGE_SIZE?
+        * KERNEL_MAPPING_SIZE?
         */
-       slots = (KERNEL_IMAGE_SIZE - minimum - image_size) /
+       slots = (KERNEL_MAPPING_SIZE - minimum - image_size) /
                 CONFIG_PHYSICAL_ALIGN + 1;

*With* kaslr, KERNEL_IMAGE_SIZE = 1G and KERNEL_MAPPING_SIZE = 1G.
Before your patch KERNEL_IMAGE_SIZE = 1G too with kaslr enabled.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

[toc] | [prev] | [next] | [standalone]

#1592031

On 03/03/17 at 11:07pm, Baoquan He wrote:
> On 03/03/17 at 03:28pm, Borislav Petkov wrote:
> > On Fri, Mar 03, 2017 at 09:11:52PM +0800, Baoquan He wrote:
> > > And another meaning of defining kernel iamge size and mapping size
> > > differently is we can randomize the limited kernel image in the mapping
> > > area. If they are the same or kernel image can be very large, the
> > > position will be fixed or very few, kernel text KASLR will be
> > > meaningless.
> > 
> > This is simply not true:
> > 
> > @@ -408,9 +408,9 @@ static unsigned long find_random_virt_addr(unsigned long minimum,
> >         /*
> >          * There are how many CONFIG_PHYSICAL_ALIGN-sized slots
> >          * that can hold image_size within the range of minimum to
> > -        * KERNEL_IMAGE_SIZE?
> > +        * KERNEL_MAPPING_SIZE?
> >          */
> > -       slots = (KERNEL_IMAGE_SIZE - minimum - image_size) /
> > +       slots = (KERNEL_MAPPING_SIZE - minimum - image_size) /
> >                  CONFIG_PHYSICAL_ALIGN + 1;
> > 
> > *With* kaslr, KERNEL_IMAGE_SIZE = 1G and KERNEL_MAPPING_SIZE = 1G.
> > Before your patch KERNEL_IMAGE_SIZE = 1G too with kaslr enabled.
> 
> 512M and 1G is the first case, just an example. Usually kernel image size
			~ worst, sorry, typo
> is only about 20M, from my laptop.
> 
> Yes, before KERNEL_IMAGE_SIZE is 1G with kaslr enabled. when you
> suggested taking a fixed size for the KERNEL_IMAGE_SIZE, but not changed
> back and forth with the kaslr set or not, I started to consider this.
> 
> See the 1G, hard-constrainted because of level2_kernel_pgt. In the
> future we could put kernel mapping area in another place to remove the
> 1G limitation, could be 10G or 512G since virtual address are so
> redundent, just an assumption, kernel KASLR can benefit from this
> actually, but we can't make upper value of kernel image size also be
> that big. That will make linker script checking lose meaning.
> 
> Thanks
> Baoquan
> 

[toc] | [prev] | [next] | [standalone]

#1592195

Ok,

TBH, I still don't like adding yet another define and paying attention
to whether I should use image size or mapping size. After your patch,
KERNEL_IMAGE_SIZE is used to enforce the actual image size from
exploding:

arch/x86/include/asm/page_32_types.h:43:#define KERNEL_IMAGE_SIZE       (512 * 1024 * 1024)
arch/x86/include/asm/page_32_types.h:49:#define KERNEL_MAPPING_SIZE     KERNEL_IMAGE_SIZE
arch/x86/include/asm/page_64_types.h:56:#define KERNEL_IMAGE_SIZE       (512 * 1024 * 1024)
arch/x86/include/asm/pgtable_32.h:83: *     (KERNEL_IMAGE_SIZE/4096) / 1024 pages (worst case, non PAE)
arch/x86/include/asm/pgtable_32.h:84: *     (KERNEL_IMAGE_SIZE/4096) / 512 + 4 pages (worst case for PAE)
arch/x86/include/asm/pgtable_32.h:91: * KERNEL_IMAGE_SIZE should be greater than pa(_end)
arch/x86/kernel/vmlinux.lds.S:356:. = ASSERT((_end - LOAD_OFFSET <= KERNEL_IMAGE_SIZE),
arch/x86/kernel/vmlinux.lds.S:357:         "kernel image bigger than KERNEL_IMAGE_SIZE");
arch/x86/kernel/vmlinux.lds.S:370:. = ASSERT((_end - _text <= KERNEL_IMAGE_SIZE),
arch/x86/kernel/vmlinux.lds.S:371:         "kernel image bigger than KERNEL_IMAGE_SIZE");

So what I'd do is keep KERNEL_IMAGE_SIZE and make it default 1G and use it
everywhere.

Then, define a separate define which is used only in vmlinux.lds.S to
enforce the size check. Having MAPPING_SIZE and IMAGE_SIZE is just
needlessly confusing.

Especially if this is just some inconsistency you're addressing and not
some real issue.

BUT(!), don't take my word for it. Rather, do what the maintainers
propose. Who knows, they might have a much better idea.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

[toc] | [prev] | [next] | [standalone]

#1592453

On 03/03/17 at 04:23pm, Borislav Petkov wrote:
> Ok,
> 
> TBH, I still don't like adding yet another define and paying attention
> to whether I should use image size or mapping size. After your patch,
> KERNEL_IMAGE_SIZE is used to enforce the actual image size from
> exploding:
> 
> arch/x86/include/asm/page_32_types.h:43:#define KERNEL_IMAGE_SIZE       (512 * 1024 * 1024)
> arch/x86/include/asm/page_32_types.h:49:#define KERNEL_MAPPING_SIZE     KERNEL_IMAGE_SIZE
> arch/x86/include/asm/page_64_types.h:56:#define KERNEL_IMAGE_SIZE       (512 * 1024 * 1024)
> arch/x86/include/asm/pgtable_32.h:83: *     (KERNEL_IMAGE_SIZE/4096) / 1024 pages (worst case, non PAE)
> arch/x86/include/asm/pgtable_32.h:84: *     (KERNEL_IMAGE_SIZE/4096) / 512 + 4 pages (worst case for PAE)
> arch/x86/include/asm/pgtable_32.h:91: * KERNEL_IMAGE_SIZE should be greater than pa(_end)
> arch/x86/kernel/vmlinux.lds.S:356:. = ASSERT((_end - LOAD_OFFSET <= KERNEL_IMAGE_SIZE),
> arch/x86/kernel/vmlinux.lds.S:357:         "kernel image bigger than KERNEL_IMAGE_SIZE");
> arch/x86/kernel/vmlinux.lds.S:370:. = ASSERT((_end - _text <= KERNEL_IMAGE_SIZE),
> arch/x86/kernel/vmlinux.lds.S:371:         "kernel image bigger than KERNEL_IMAGE_SIZE");
> 
> So what I'd do is keep KERNEL_IMAGE_SIZE and make it default 1G and use it
> everywhere.
> 
> Then, define a separate define which is used only in vmlinux.lds.S to
> enforce the size check. Having MAPPING_SIZE and IMAGE_SIZE is just
> needlessly confusing.

Yes, in fact if only look at 64 bit, what I am doing is just as you
suggested. KERNEL_IMAGE_SIZE is only used to limit the image size,
namely _end - _text.

. = ASSERT((_end - _text <= KERNEL_IMAGE_SIZE),
           "kernel image bigger than KERNEL_IMAGE_SIZE");

And I could get what's confusing, should be the name of
KERNEL_MAPPING_SIZE. If only talking about the kernel itself, the
mapping size needed to cover the whole kernel iamge should be the same
as kernel image size. Say kernel image size ( _end - _text) is 86M, then
if kaslr-ed to a postion at 0xffffffffa0000000, which is 512M above the
starting address of virtual address space used for kernel mapping, the
kernel iamge will be mapped at region:
	[0xffffffffa0000000, 0xffffffffa5600000]

So here KERNEL_MAPPING_SIZE is not meaning the size of the mapping
region of kernel image itself, but the whole virtual address space which
is available only for kernel mapping, nobody else can touch this area.
It's 1G big, and cover region [0xffffffff80000000, 0xffffffffbfffffff].
It might be named as SIZE_OF_SPACE_FOR_KERNEL_MAPPING, but that is not a
good name, so I just named as KERNEL_MAPPING_SIZE. It could be
confusing.

> 
> Especially if this is just some inconsistency you're addressing and not
> some real issue.

I think it's not simply fixing inconsistency thing now, according to a
lot of discussion, we all agree that there's no need to change the size
of space for kernel mapping back and forth, 512M to 1G, 1G back to 512M,
risk isn't felt when shrink kernel modules space to 1G constantly.

> 
> BUT(!), don't take my word for it. Rather, do what the maintainers
> propose. Who knows, they might have a much better idea.

Sorry about that. Just think your words are very convincing on removing
people's doubt if it's risky to shrink kernel modules space to 1G. Will
remove the words mentioning you said it since you don't like it. Didn't
realize that, no offence.

Thanks
Baoquan

[toc] | [prev] | [next] | [standalone]

#1592471

On Sat, Mar 04, 2017 at 06:10:37PM +0800, Baoquan He wrote:
> > BUT(!), don't take my word for it. Rather, do what the maintainers
> > propose. Who knows, they might have a much better idea.
> 
> Sorry about that. Just think your words are very convincing on removing
> people's doubt if it's risky to shrink kernel modules space to 1G. Will
> remove the words mentioning you said it since you don't like it. Didn't
> realize that, no offence.

No, this is not what I mean at all!

I'm saying, I tried to review your patches and I don't like the end
result because it adds more complexity. And the reason(s) for it are not
persuading me enough to make me say: "yeah, this is a good thing, I want
it."

But this is only my opinion. That's all. The final decision is in the
hands of the x86 maintainers.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

[toc] | [prev] | [next] | [standalone]

#1592499

On 03/04/17 at 12:55pm, Borislav Petkov wrote:
> On Sat, Mar 04, 2017 at 06:10:37PM +0800, Baoquan He wrote:
> > > BUT(!), don't take my word for it. Rather, do what the maintainers
> > > propose. Who knows, they might have a much better idea.
> > 
> > Sorry about that. Just think your words are very convincing on removing
> > people's doubt if it's risky to shrink kernel modules space to 1G. Will
> > remove the words mentioning you said it since you don't like it. Didn't
> > realize that, no offence.
> 
> No, this is not what I mean at all!
> 
> I'm saying, I tried to review your patches and I don't like the end
> result because it adds more complexity. And the reason(s) for it are not
> persuading me enough to make me say: "yeah, this is a good thing, I want
> it."
> 
> But this is only my opinion. That's all. The final decision is in the
> hands of the x86 maintainers.

Got it, sorry for the misunderstanding. I really appreciate your
reviewing, great comments and suggestions. Glad to see that now we
don't hesitate to shrink kernel modules area to 1G after discussion. I
will ping Ingo to ask if he has any suggestion since he has been taking
care of the KERNEL_IMAGE_SIZE value changing.

Thanks
Baoquan

[toc] | [prev] | [next] | [standalone]

#1592033

On 03/03/17 at 03:28pm, Borislav Petkov wrote:
> On Fri, Mar 03, 2017 at 09:11:52PM +0800, Baoquan He wrote:
> > And another meaning of defining kernel iamge size and mapping size
> > differently is we can randomize the limited kernel image in the mapping
> > area. If they are the same or kernel image can be very large, the
> > position will be fixed or very few, kernel text KASLR will be
> > meaningless.
> 
> This is simply not true:
> 
> @@ -408,9 +408,9 @@ static unsigned long find_random_virt_addr(unsigned long minimum,
>         /*
>          * There are how many CONFIG_PHYSICAL_ALIGN-sized slots
>          * that can hold image_size within the range of minimum to
> -        * KERNEL_IMAGE_SIZE?
> +        * KERNEL_MAPPING_SIZE?
>          */
> -       slots = (KERNEL_IMAGE_SIZE - minimum - image_size) /
> +       slots = (KERNEL_MAPPING_SIZE - minimum - image_size) /
>                  CONFIG_PHYSICAL_ALIGN + 1;
> 
> *With* kaslr, KERNEL_IMAGE_SIZE = 1G and KERNEL_MAPPING_SIZE = 1G.
> Before your patch KERNEL_IMAGE_SIZE = 1G too with kaslr enabled.

512M and 1G is the first case, just an example. Usually kernel image size
is only about 20M, from my laptop.

Yes, before KERNEL_IMAGE_SIZE is 1G with kaslr enabled. when you
suggested taking a fixed size for the KERNEL_IMAGE_SIZE, but not changed
back and forth with the kaslr set or not, I started to consider this.

See the 1G, hard-constrainted because of level2_kernel_pgt. In the
future we could put kernel mapping area in another place to remove the
1G limitation, could be 10G or 512G since virtual address are so
redundent, just an assumption, kernel KASLR can benefit from this
actually, but we can't make upper value of kernel image size also be
that big. That will make linker script checking lose meaning.

Thanks
Baoquan

[toc] | [prev] | [next] | [standalone]

#1592053

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@elte.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)
> -- 

[toc] | [prev] | [next] | [standalone]

#1592086

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.

> 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)
-- 

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web