Re: Oops in 3.7-rc8 isolate_free_pages_block()

[Mel Gorman]

On Thu, Dec 06, 2012 at 08:10:13AM -0800, Linus Torvalds wrote:
> Ok, so it's isolate_freepages_block+0x88, and as Jan Kara already
> guessed from just the offset, that is indeed likely the PageBuddy()
> test.
> 
> On Thu, Dec 6, 2012 at 7:22 AM, Henrik Rydberg <rydberg@xxxxxxxxxxx> wrote:
> >
> >  http://bitmath.org/test/oops-3.7-rc8.jpg
> >
> > ffffffff810a6d6a:       eb 1c                   jmp    ffffffff810a6d88 <isolate_freepages_block+0x88>
> > ffffffff810a6d6c:       0f 1f 40 00             nopl   0x0(%rax)
> 
> On the first entry to the loop, we jump *into* the loop, over the end
> condition (the compiler has basically turned. And we jump directly to
> the faulting instruction. Looking at the register state, though, we're
> not at the first iteration of the loop, so we don't have to worry
> about that case. The loop itself then starts with:
> 
> > ffffffff810a6d70:       48 83 c5 01             add    $0x1,%rbp
> > ffffffff810a6d74:       48 83 c3 40             add    $0x40,%rbx
> 
> The above is the "blockpfn++, cursor++" part of the loop, while the
> test below is the loop condition ("blockpfn < end_pfn"):
> 
> > ffffffff810a6d78:       49 39 ed                cmp    %rbp,%r13
> > ffffffff810a6d7b:       0f 86 cf 00 00 00       jbe    ffffffff810a6e50 <isolate_freepages_block+0x150>
> 
> From your image, %rbp is 0x070000 and %r13 is 0x0702f9.
> 
> The "pfn_valid_within()" test is a no-op because we don't have holes
> in zones on x86, so then we have
> 

That thing is not about holes in zones, it's about holes within a
MAX_ORDER_NR_PAGES block but either way it's a no-op x86 and we're not doing
a pfn_valid check in this loop. I didn't look back in time but I have a
vague recollection that this used to be always start with an aligned PFN
but with large amounts of churn since, it's no longer true.

>                 if (!valid_page)
>                         valid_page = page;
> 
> which generates a test+cmove:
> 
> > ffffffff810a6d81:       4d 85 e4                test   %r12,%r12
> > ffffffff810a6d84:       4c 0f 44 e3             cmove  %rbx,%r12
> 
> (which is how we can tell we're not at the beginning: 'valid_page' is
> 0xffffea0001bfbe40, while the current page is 0xffffea0001c00000).
> 
> .. and finally the oopsing instruction from PageBuddy(), which is the
> read of the 'page->_mapcount'
> 
> > ffffffff810a6d88:       8b 43 18                mov    0x18(%rbx),%eax
> > ffffffff810a6d8b:       83 f8 80                cmp    $0xffffff80,%eax
> > ffffffff810a6d8e:       75 e0                   jne    ffffffff810a6d70 <isolate_freepages_block+0x70>
> 
> So yeah, that loop has apparently wandered into la-la-land. end_pfn
> must be somehow wrong.
> 

I think we wandered into a hole where there is no valid struct page.

> Mel, does any of this ring a bell (Andrew also added to the cc, since
> the patches came through him).
> 

It reminded me of a similar bug in the migration scanner which I mentioned
in the patch elsewhere in the thread but carelessly failed to cc Andrew.
--
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/