Re: 2.6.15-rc4 panic in __nr_to_section() with CONFIG_SPARSEMEM

[Dave Hansen <haveblue@us.ibm.com>]

On Wed, 2005-12-07 at 15:22 -0800, Badari Pulavarty wrote:
> BTW, the problem seems to be while dealing with shared memory areas
> that are backed by largepages.

I think this is likely not directly a sparsemem problem.  It probably
just shows symptoms earlier.

See the attached patch.  It attempts to detect and handle hugetlb pages
in the smaps code.  However, I think one of the root issues here is that
bad_pmd() triggers for hugetlb pmds.  I audited a few places where it is
called, and at least a couple of them can't have hugepages handed into
them, like fork().

-- Dave



---

 proc-dups-dave/fs/proc/task_mmu.c |   22 ++++++++++++++++++++++
 1 files changed, 22 insertions(+)

diff -puN fs/proc/task_mmu.c~task_mmu_fix fs/proc/task_mmu.c
--- proc-dups/fs/proc/task_mmu.c~task_mmu_fix	2005-12-07 16:34:38.000000000 -0800
+++ proc-dups-dave/fs/proc/task_mmu.c	2005-12-07 16:34:47.000000000 -0800
@@ -245,6 +245,28 @@ static inline void smaps_pmd_range(struc
 	pmd = pmd_offset(pud, addr);
 	do {
 		next = pmd_addr_end(addr, end);
+
+		if (pmd_huge(*pmd)) {
+			struct page *page;
+
+			page = follow_huge_pmd(vma->vm_mm, addr, pmd, 0);
+			if (!page)
+				continue;
+
+			mss->resident += HPAGE_SIZE;
+			if (page_count(page) >= 2) {
+				if (pte_dirty(*(pte_t *)pmd))
+					mss->shared_dirty += HPAGE_SIZE;
+				else
+					mss->shared_clean += HPAGE_SIZE;
+			} else {
+				if (pte_dirty(*(pte_t *)pmd))
+					mss->private_dirty += HPAGE_SIZE;
+				else
+					mss->private_clean += HPAGE_SIZE;
+			}
+			continue;
+		}
 		if (pmd_none_or_clear_bad(pmd))
 			continue;
 		smaps_pte_range(vma, pmd, addr, next, mss);
_