From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sat, 3 Apr 2004 17:20:26 +0200 From: Andrea Arcangeli Subject: Re: [RFC][PATCH 1/3] radix priority search tree - objrmap complexity fix Message-ID: <20040403152026.GE2307@dualathlon.random> References: <20040402011627.GK18585@dualathlon.random> <20040401173649.22f734cd.akpm@osdl.org> <20040402020022.GN18585@dualathlon.random> <20040402104334.A871@infradead.org> <20040402164634.GF21341@dualathlon.random> <20040402195927.A6659@infradead.org> <20040402192941.GP21341@dualathlon.random> <20040402205410.A7194@infradead.org> <20040402203514.GR21341@dualathlon.random> <20040403094058.A13091@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040403094058.A13091@infradead.org> Sender: owner-linux-mm@kvack.org Return-Path: To: Christoph Hellwig , Andrew Morton , hugh@veritas.com, vrajesh@umich.edu, linux-kernel@vger.kernel.org, linux-mm@kvack.org List-ID: On Sat, Apr 03, 2004 at 09:40:58AM +0100, Christoph Hellwig wrote: > On Fri, Apr 02, 2004 at 10:35:14PM +0200, Andrea Arcangeli wrote: > > how can that be the second one? (I deduced it was the first one because > > it cannot be the second one and the offset didn't look at the very end > > of the function). This is the second one: > > > > if (!PageCompound(p)) > > bad_page(__FUNCTION__, p); > > > > but bad_page shows p->flags == 0x00080008 and 1< > 0x80000. > > > > So PG_compound is definitely set for "p" and it can't be the second one > > triggering. > > > > Can you double check? Maybe we should double check the asm. Something > > sounds fundamentally wrong in the asm, sounds like a miscompilation, > > which compiler are you using? > > Because I didn't trust my ppc assembly reading that much I put in a printk > and it's actually the third bad_page(), sorry. ok no problem, so page->private got screwed. I cannot see what could change page->private though. I should also have noticed myself that page->private was wrong: 0xc07721ff is not a 4byte aligned address, that explains the weird page count too, since page_count follows page->private to return the page->count of the master page. I've no idea what could set page->private to such a weird address. the "p" page is at address c0772380, that seems sane, the page->flags and page->mapping as well are sane (p->count cannot be seen, what we see is p->private->count), only page->private is screwed apparently. if you want you can give a spin to this patch. As far as the old code worked (i.e. with hugetlbfs=n) this should work too, since it disables the compound feature completely, but if it works it probably only hides the real bug. You can use rc3-aa3 for this (it already has the latest robustness fixes I posted to you) --- x/mm/page_alloc.c.~1~ 2004-04-02 20:37:14.000000000 +0200 +++ x/mm/page_alloc.c 2004-04-03 17:15:52.647449336 +0200 @@ -563,7 +563,9 @@ __alloc_pages(unsigned int gfp_mask, uns cold = 0; if (gfp_mask & __GFP_COLD) cold = __GFP_COLD; +#if 0 if (gfp_mask & __GFP_NO_COMP) +#endif cold |= __GFP_NO_COMP; zones = zonelist->zones; /* the list of zones suitable for gfp_mask */ -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: aart@kvack.org