Re: [memcg BUG] unable to handle kernel NULL pointer derefence at 00000000

[Balbir Singh <balbir@linux.vnet.ibm.com>]

KAMEZAWA Hiroyuki wrote:
> On Tue, 21 Oct 2008 17:54:28 +0800
> Li Zefan <lizf@cn.fujitsu.com> wrote:
> 
>> KAMEZAWA Hiroyuki wrote:
>>> On Tue, 21 Oct 2008 17:13:20 +0800
>>> Li Zefan <lizf@cn.fujitsu.com> wrote:
>>>
>>>> KAMEZAWA Hiroyuki wrote:
>>>>> On Tue, 21 Oct 2008 16:35:09 +0800
>>>>> Li Zefan <lizf@cn.fujitsu.com> wrote:
>>>>>
>>>>>> KAMEZAWA Hiroyuki wrote:
>>>>>>> On Tue, 21 Oct 2008 15:21:07 +0800
>>>>>>> Li Zefan <lizf@cn.fujitsu.com> wrote:
>>>>>>>> dmesg is attached.
>>>>>>>>
>>>>>>> Thanks....I think I caught some. (added Mel Gorman to CC:)
>>>>>>>
>>>>>>> NODE_DATA(nid)->spanned_pages just means sum of zone->spanned_pages in node.
>>>>>>>
>>>>>>> So, If there is a hole between zone, node->spanned_pages doesn't mean
>>>>>>> length of node's memmap....(then, some hole can be skipped.)
>>>>>>>
>>>>>>> OMG....Could you try this ? 
>>>>>>>
>>>>>> No luck, the same bug still exists. :(
>>>>>>
>>>>> This is a little fixed one..
>>>>>
>>>> I tried the patch, but it doesn't solve the problem..
>>>>
>>> Hmm.. Can you catch "pfn" of troublesome page_cgroup ?
>>> By patch like this ?
>>>
>> I got what you want:
>>
>> pc c1d589dc pc->page 00000000 page c105f67c pfn 1d5b
>> ...
>> pc c1d589f0 pc->page 00000000 page c105f6b0 pfn 1d5c
>>
> Oh! thanks...but it seems pc->page is NULL in the middle of ZONE_NORMAL..
> ==
>  Normal   0x00001000 -> 0x000373fe
> ==
> This is appearently in the range of page_cgroup initialization.
> (if pgdat->node_page_cgroup is initalized correctly.. == .)
> 
> I think write to page_cgroup->page happens only at initialization.
> Hmm ? not initilization failure but curruption ?
> 


0x3bff0 = 245744
Looking at dmesg, we used 4914560 for page_cgroup, page_cgroup is 20 bytes, so
the number of page_cgroups we have = 245728. The difference is 16

That would make sense, if we look at

early_node_map[2] active PFN ranges
    0: 0x00000010 -> 0x0000009f
    0: 0x00000100 -> 0x0003bff0

Node 0 starts from pfn 0x10 == 16.

OK, so we were able to allocate the page_cgroup, so either

1) Like Kamezawa suggested, there was corruption (very unlikely)
2) pfn_to_page() returned NULL
3) We did not initialize a certain set of page_cgroups

> What happens if replacing __alloc_bootmem() with vmalloc() in page_cgroup.c init ?


-- 
	Balbir

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>