Re: [bug] mm/slab.c boot crash in -git, "kernel BUG at mm/slab.c:2103!"

From: Nick Piggin
Date: Fri Apr 11 2008 - 06:34:46 EST


On Fri, Apr 11, 2008 at 11:24:52AM +0200, Ingo Molnar wrote:
>
> * Pekka Enberg <penberg@xxxxxxxxxxxxxx> wrote:
>
> > On Fri, Apr 11, 2008 at 12:05 PM, Pekka Enberg <penberg@xxxxxxxxxxxxxx> wrote:
> > > > Right. Then you probably want to look into any changes in arch/x86/
> > > > related to setting up the zonelists. I'm fairly certain this is not a
> > > > slab bug and I don't see any recent changes to the page allocator
> > > > either that would explain this.
> > >
> > > I'd be willing to put some money on this:
> > >
> > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b7ad149d62ffffaccb9f565dfe7e5bae739d6836
> >
> > And I'd lose as you're 32-bit. Oh well, that's the price to pay for
> > pretending to know x86 arch internals.
>
> yeah, sorry - we are working hard to unify generic bits like that, but
> it's a huge architecture.

BTW. I think I'm seeing some problems perhaps related to change page
attr stuff for DEBUG_PAGEALLOC on x86-64. And I don't know if it is the
same thing, but some general instability around either the page allocator
or slab allocator.

The debug pagealloc problems seem to be that a thread suddenly get stuck
in the kernel spinning in cpa (usually on one of the locks) and never
seems to recover. Once it seemed to be spinning in clear_page_... too,
but perhaps could it be messing up the page attributes and running so
slowly that it just appears to be hanging? I'll try to get more info here
but it is hard to reproduce.

The general instability -- I've just seen an oops or two in the page
allocation path in slub recently. Nothing reportable because I've been
running my own patches and/or been unable to reproduce... but it is a bit
unusual and I'll keep an eye out.

Anyway, I'd suggest cooking this kernel a bit longer before release...

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