On Thu, Aug 02, 2007 at 12:40:59AM +0100, Mel Gorman wrote:
This implies that &page->lru is invalid. Which implies that the memory
map is indeed not present. However, if we look at the code in detail we
have actually already updated several fields in the struct page already.
Particularly we have already updated the flags, _count, and _mapcount.
It is when we touch lru which we blammo. All of the good entries are in
the first 24 bytes of the struct page, lru is in the 8th 64bit word, or
+64 bytes. Looking at the faulting address it is ffffe20003000010, ie
the fault is 16 bytes into a page. So the first three elements of this
struct page are in one PMD mapped page, and the lru the next.
As this has SPARSEMEM_VMEMMAP enabled that implies that the vemmmap has
not been filled out correctly. Looking at the x86_64 initialiser it
appears that we have the same bug that Kame-san reported against the
generic initialisers. At the end of this email is a proposed patch for
this, could you apply that to a clean 2.6.23-rc1-mm2 tree and give it
a test for me. I have boot tested this on our x86_64 boxes, but they
happen to be sized and layed out to not trip this bug.
Let me know if it fixes things up for you and I will push it upstream.
If this patch does not fix it could you please get us a boot log at
loglevel=8 of an unmodified 2.6.23-rc1-mm2 kernel, this should give
sufficient debug on how the vmemmap is initialised.
[...]
-apw
=== 8< ===
vmemmap x86_64: ensure end of section memmap is initialised
Similar to the generic initialisers, the x86_64 vmemmap
initialisation may incorrectly skip the last page of a section if
the section start is not aligned to the page.
Where we have a section spanning the end of a PMD we will check the
start of the section at A populating it. We will then move on 1
PMD page to C and find ourselves beyond the end of the section which
ends at B we will complete without checking the second PMD page.
| PMD | PMD |
| SECTION |
A B C
We should round ourselves to the end of the PMD as we iterate.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
---
arch/x86_64/mm/init.c | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/x86_64/mm/init.c b/arch/x86_64/mm/init.c
index ac49df0..5d1ed03 100644
--- a/arch/x86_64/mm/init.c
+++ b/arch/x86_64/mm/init.c
@@ -792,9 +792,10 @@ int __meminit vmemmap_populate_pmd(pud_t *pud, unsigned long addr,
unsigned long end, int node)
{
pmd_t *pmd;
+ unsigned long next;
- for (pmd = pmd_offset(pud, addr); addr < end;
- pmd++, addr += PMD_SIZE)
+ for (pmd = pmd_offset(pud, addr); addr < end; pmd++, addr = next) {
+ next = pmd_addr_end(addr, end);
if (pmd_none(*pmd)) {
pte_t entry;
void *p = vmemmap_alloc_block(PMD_SIZE, node);
@@ -808,8 +809,8 @@ int __meminit vmemmap_populate_pmd(pud_t *pud, unsigned long addr,
printk(KERN_DEBUG " [%lx-%lx] PMD ->%p on node %d\n",
addr, addr + PMD_SIZE - 1, p, node);
} else
- vmemmap_verify((pte_t *)pmd, node,
- pmd_addr_end(addr, end), end);
+ vmemmap_verify((pte_t *)pmd, node, next, end);
+ }
return 0;
}
#endif
-
