Re: x86: early boot crash: "alloc_low_page: ran out of memory" (bisected)

[Yinghai Lu]

On Fri, Aug 9, 2013 at 4:18 PM, Dave Hansen <dave.hansen@xxxxxxxxx> wrote:
> I'm getting a 100% reproducible panic early in boot:
>
>> [    0.000000] Kernel panic - not syncing: alloc_low_page: ran out of memory
>
> I'm not sure why I didn't run in to this until now.  I think there are a
> couple of config options that need to get set just right to trigger it,
> but CONFIG_DEBUG_PAGEALLOC seems to be the main one.  Full config is here:
>
>         http://sr71.net/~dave/intel/foo/config-bigbox-crash-20130809.txt
>
> I bisected it back to this commit (which I seem to remember causing some
> other probems):
>
>> commit 8170e6bed465b4b0c7687f93e9948aca4358a33b
>> Author: H. Peter Anvin <hpa@xxxxxxxxx>
>> Date:   Thu Jan 24 12:19:52 2013 -0800
>>
>>     x86, 64bit: Use a #PF handler to materialize early mappings on demand
>
> I need somewhere between 500G and 600G of memory to trigger it, but it
> can be triggered using qemu with much less _actual_ RAM than that.  From
> looking at the dmesg diffs, I suspect that the delta in memory use
> between using 1G and 4k ptes for the identity mapping (DEBUG_PAGEALLOC
> forces 4k pages) is the proximate trigger.
>
> I also suspect that alloc_low_pages() is buggy in the way it manipulates
> min/max_pfn_mapped.  I'm quite baffled how 'max_pfn_mapped' is supposed
> to get set up correctly.  Current code says:
>
>         max_pfn_mapped = 0; /* will get exact value next */
>
> but I certainly don't see it getting set later on in that function, or
> _ever_ as adding some printk()'s shows:
>
>> +[    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
>> +[    0.000000]  [mem 0x00000000-0x000fffff] page 4k
>> +[    0.000000] alloc_low_pages(1) min_pfn_mapped: 0 max_pfn_mapped: 0
>> +[    0.000000] BRK [0x02086000, 0x02086fff] PGTABLE
>> +[    0.000000] alloc_low_pages(1) min_pfn_mapped: 0 max_pfn_mapped: 0
>> +[    0.000000] BRK [0x02087000, 0x02087fff] PGTABLE
>> +[    0.000000] alloc_low_pages(1) min_pfn_mapped: 0 max_pfn_mapped: 0
>> +[    0.000000] BRK [0x02088000, 0x02088fff] PGTABLE
>> +[    0.000000] init_memory_mapping: [mem 0xf07fe00000-0xf07fffffff]
>> +[    0.000000]  [mem 0xf07fe00000-0xf07fffffff] page 4k
>> +[    0.000000] alloc_low_pages(1) min_pfn_mapped: 252182528 max_pfn_mapped: 0
>> +[    0.000000] BRK [0x02089000, 0x02089fff] PGTABLE
>> +[    0.000000] alloc_low_pages(1) min_pfn_mapped: 252182528 max_pfn_mapped: 0
>> +[    0.000000] BRK [0x0208a000, 0x0208afff] PGTABLE
>> +[    0.000000] alloc_low_pages(1) min_pfn_mapped: 252182528 max_pfn_mapped: 0
>> +[    0.000000] Kernel panic - not syncing: alloc_low_page: ran out of memory
>
> I'll take a closer look at it next week, but figured I'd report it first.
>
> Full dmesg:
>
>> early console in setup code
>> [    0.000000] Initializing cgroup subsys cpuset
>> [    0.000000] Initializing cgroup subsys cpu
>> [    0.000000] Linux version 3.8.0-rc5-00059-g8170e6b

so how about v3.10?

We should have some fixes in 3.10 already.

Thanks

Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/