Re: tipc_init(), WARNING: at arch/x86/mm/highmem_32.c:52, [2.6.24-rc4-git5: Reported regressions from 2.6.23]

[Matt Mackall <mpm@selenic.com>]

On Sat, Dec 08, 2007 at 09:54:06AM -0800, Linus Torvalds wrote:
> 
> 
> On Sat, 8 Dec 2007, Linus Torvalds wrote:
> > 
> > But I'll apply it anyway, because it looks "obviously correct" from the 
> > standpoint that the _other_??slob user already clears the end result 
> > explicitly later on, and we simply should never pass down __GFP_ZERO to 
> > the actual page allocator.
> 
> Actually, I take that back. The other slob users are different. They share 
> pages, this codepath does not.
> 
> So I think a more proper solution would be:
>  (a) Something like this patch (which includes my previous mm/slub.c 
>      change)
>  (b) don't warn about atomic GFP_ZERO's - unless they have GFP_HIGHMEM set 
>      *too*.
> 
> So which warning is it that triggers the bogus error?

While I think the whole GFP_ZERO thing is a bit broken here, this is
an improvement on my original patch, so:

Acked-by: Matt Mackall <mpm@selenic.com>
> ---
>  mm/slob.c |    2 +-
>  mm/slub.c |    3 +++
>  2 files changed, 4 insertions(+), 1 deletions(-)
> 
> diff --git a/mm/slob.c b/mm/slob.c
> index ee2ef8a..773a7aa 100644
> --- a/mm/slob.c
> +++ b/mm/slob.c
> @@ -330,7 +330,7 @@ static void *slob_alloc(size_t size, gfp_t gfp, int align, int node)
>  
>  	/* Not enough space: must allocate a new page */
>  	if (!b) {
> -		b = slob_new_page(gfp, 0, node);
> +		b = slob_new_page(gfp & ~__GFP_ZERO, 0, node);
>  		if (!b)
>  			return 0;
>  		sp = (struct slob_page *)virt_to_page(b);
> diff --git a/mm/slub.c b/mm/slub.c
> index b9f37cb..9c1d9f3 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -1468,6 +1468,9 @@ static void *__slab_alloc(struct kmem_cache *s,
>  	void **object;
>  	struct page *new;
>  
> +	/* We handle __GFP_ZERO in the caller */
> +	gfpflags &= ~__GFP_ZERO;
> +
>  	if (!c->page)
>  		goto new_slab;

-- 
Mathematics is the supreme nostalgia of our time.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/