diff options
author | Ingo Molnar <mingo@elte.hu> | 2008-01-15 16:44:37 +0100 |
---|---|---|
committer | Ingo Molnar <mingo@elte.hu> | 2008-01-15 16:44:37 +0100 |
commit | 23be8c7ddf4fd31a14579a2109c89845f7a0fbb6 (patch) | |
tree | 57d28dd27783e79273c9a2c6e3c4307c0ac945e1 /drivers/net/macvlan.c | |
parent | 5d5d80001df3fbd06bd2b8893b6e3847e38a12d6 (diff) |
x86: fix boot crash on HIGHMEM4G && SPARSEMEM
Denys Fedoryshchenko reported a bootup crash when he upgraded
his system from 3GB to 4GB RAM:
http://lkml.org/lkml/2008/1/7/9
the bug is due to HIGHMEM4G && SPARSEMEM kernels making pfn_to_page()
to return an invalid pointer when the pfn is in a memory hole. The
256 MB PCI aperture at the end of RAM was not mapped by sparsemem,
and hence the pfn was not valid. But set_highmem_pages_init() iterated
this range without checking the pfn's validity first.
this bug was probably present in the sparsemem code ever since sparsemem
has been introduced in v2.6.13. It was masked due to HIGHMEM64G using
larger memory regions in sparsemem_32.h:
#ifdef CONFIG_X86_PAE
#define SECTION_SIZE_BITS 30
#define MAX_PHYSADDR_BITS 36
#define MAX_PHYSMEM_BITS 36
#else
#define SECTION_SIZE_BITS 26
#define MAX_PHYSADDR_BITS 32
#define MAX_PHYSMEM_BITS 32
#endif
which creates 1GB sparsemem regions instead of 64MB sparsemem regions.
So in practice we only ever created true sparsemem holes on x86 with
HIGHMEM4G - but that was rarely used by distros.
( btw., we could probably save 2MB of mem_map[]s on X86_PAE if we reduced
the sparsemem region size to 256 MB. )
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Diffstat (limited to 'drivers/net/macvlan.c')
0 files changed, 0 insertions, 0 deletions