Re: [PATCH] Fix mm regression bug: nommu use compound page in slab allocator

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Luke,

On 3/31/06, Luke Yang <[email protected]> wrote:
>   The earlier patch to consolidate mmu and nommu page allocation
> and refcounting by using compound pages for nommu allocations
> had a bug: kmalloc slabs who's pages were initially allocated
> by a non-__GFP_COMP allocator could be passed into mm/nommu.c
> kmalloc allocations which really wanted __GFP_COMP underlying
> pages. Fix that by having nommu pass __GFP_COMP to all higher order
> slab allocations.

Any reason we are not doing this for CONFIG_MMU as well? We could then
fix the slab callers to not pass __GFP_COMP at all which seems broken
anyway.

                                 Pekka

> Signed-off-by: Luke Yang <[email protected]>
> Acked-by: Nick Piggin <[email protected]>
>
>  slab.c |    4 ++++
> 1 files changed, 4 insertions(+)
>
> diff --git a/mm/slab.c b/mm/slab.c
> index 4cbf8bb..388a6a9 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -1454,7 +1454,11 @@ static void *kmem_getpages(struct kmem_c
>         int i;
>
>         flags |= cachep->gfpflags;
> +#ifdef CONFIG_MMU
>         page = alloc_pages_node(nodeid, flags, cachep->gfporder);
> +#else
> +       page = alloc_pages_node(nodeid, (flags | __GFP_COMP), cachep->gfporder);
> +#endif
>         if (!page)
>                 return NULL;
>         addr = page_address(page);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux