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

KAMEZAWA Hiroyuki
2008-10-22T02:31:34Z

On Wed, 22 Oct 2008 11:13:31 +0900
Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp> wrote:

> On Tue, 21 Oct 2008 20:32:15 +0900, KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> > On Tue, 21 Oct 2008 13:28:43 +0200
> > Ingo Molnar <mingo@elte.hu> wrote:
> >
> > >
> > > * KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> > >
> > > > On Tue, 21 Oct 2008 13:19:51 +0200
> > > > Ingo Molnar <mingo@elte.hu> wrote:
> > > >
> > > > >
> > > > > * Li Zefan <lizf@cn.fujitsu.com> wrote:
> > > > >
> > > > > > > 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 ?
> > > > > > >
> > > > > >
> > > > > > Yes, curruption. I didn't find informatation about initialization failure.
> > > > > >
> > > > > > > What happens if replacing __alloc_bootmem() with vmalloc() in page_cgroup.c init ?
> > > > > > >
> > > > > >
> > > > > > So I did this change, and the box booted up without any problem.
> > > > > >
> > > > > > diff --git a/mm/page_cgroup.c b/mm/page_cgroup.c
> > > > > > index 5d86550..82a30b1 100644
> > > > > > --- a/mm/page_cgroup.c
> > > > > > +++ b/mm/page_cgroup.c
> > > > > > @@ -48,8 +48,7 @@ static int __init alloc_node_page_cgroup(int nid)
> > > > > >
> > > > > > table_size = sizeof(struct page_cgroup) * nr_pages;
> > > > > >
> > > > > > - base = __alloc_bootmem_node_nopanic(NODE_DATA(nid),
> > > > > > - table_size, PAGE_SIZE, __pa(MAX_DMA_ADDRESS));
> > > > > > + base = vmalloc_node(table_size, nid);
> > > > > > if (!base)
> > > > > > return -ENOMEM;
> > > > >
> > > > > i have this:
> > > > >
> > > > > CONFIG_FAILSLAB=y
> > > > > CONFIG_FAIL_PAGE_ALLOC=y
> > > > > # CONFIG_FAIL_MAKE_REQUEST is not set
> > > > > CONFIG_FAIL_IO_TIMEOUT=y
> > > > >
> > > > > so the bug was perhaps that the __alloc_bootmem_node_nopanic() failed
> > > > > and this code continued silently? vmalloc_node() probably is more
> > > > > agressive about allocating memory.
> > > > >
> > > > Sorry. I think I cannot use alloc_bootmem() at this point because
> > > > it's too late in init-path. (we can use usual page allocator)
> > > > So, just replacing alloc_bootmem() with vmalloc_node() is a fix....
> > >
> > > okay. So what is needed for the crash is:
> > >
> > > CONFIG_CGROUPS=y
> > > CONFIG_CGROUP_MEM_RES_CTLR=y
> > >
> > yes. maybe. I think you can avoid crash by cgroup_disable=memory boot option.
> > But Nishimura reports he cannot boot with cgroup_disable=memory. So I wonder
> > there may be something other. But calling alloc_bootmem() here should be avoided.
> >
> The "hang on boot" problem I reported hapens also on !CONFIG_CGROUP kernel too,
> and it seems to be H/W dependent.
>
> I'll dig more when I have time.
>
Oh, thank you for reporting. (my own small box hangs too but I couldn't find why yet.)

Thanks,
-Kame