Re: [RFC][PATCH 1/3] radix priority search tree - objrmap complexity fix

[Andrea Arcangeli]

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