[BUG] 2.6.25-rc3-mm1 kernel panic while bootup on powerpc ()

[Mel Gorman]

On (04/03/08 12:34), Andrew Morton didst pronounce:
> On Tue, 4 Mar 2008 12:07:39 -0800 (PST)
> Christoph Lameter <clameter at sgi.com> wrote:
> 
> > I think this is the correct fix.
> > 
> > The NUMA fallback logic should be passing local_flags to kmem_get_pages() 
> > and not simply the flags.
> > 
> > Maybe a stable candidate since we are now simply 
> > passing on flags to the page allocator on the fallback path.
> 
> Do we know why this is only reported in 2.6.25-rc3-mm1?
> 
> Why does this need fixing in 2.6.24.x?
> 

I don't believe it needs to be fixed in 2.6.24.3. The call-sites in
lib/radix-tree.c there look like

        ret = kmem_cache_alloc(radix_tree_node_cachep,
                                set_migrateflags(gfp_mask, __GFP_RECLAIMABLE));

        node = kmem_cache_alloc(radix_tree_node_cachep,
                               set_migrateflags(gfp_mask, __GFP_RECLAIMABLE));

and set_migrateflags() looks like

#define GFP_MOVABLE_MASK (__GFP_RECLAIMABLE|__GFP_MOVABLE)
static inline gfp_t set_migrateflags(gfp_t gfp, gfp_t migrate_flags)
{
        BUG_ON((gfp & GFP_MOVABLE_MASK) == GFP_MOVABLE_MASK);
        return (gfp & ~(GFP_MOVABLE_MASK)) | migrate_flags;
}

so the flags were already getting cleared and the WARN_ON could not
trigger in this path. In 2.6.25-rc3-mm1, the patch
remove-set_migrateflags.patch gets rid of set_migateflags()
which led to this situation.

The surprise is that it didn't get caught in an earlier -mm but it could
be because it only affected slab.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab