From: Dave Hansen <haveblue@us.ibm.com>
To: Badari Pulavarty <pbadari@us.ibm.com>
Cc: David Gibson <dwg@au1.ibm.com>, Andy Whitcroft <andyw@uk.ibm.com>,
lkml <linux-kernel@vger.kernel.org>,
"ADAM G. LITKE [imap]" <agl@us.ibm.com>
Subject: Re: 2.6.15-rc4 panic in __nr_to_section() with CONFIG_SPARSEMEM
Date: Mon, 12 Dec 2005 13:28:09 -0800 [thread overview]
Message-ID: <1134422889.27961.22.camel@localhost> (raw)
In-Reply-To: <1134404367.2193.14.camel@localhost.localdomain>
On Mon, 2005-12-12 at 08:19 -0800, Badari Pulavarty wrote:
> NACK.
>
> Like I mentioned to you privately, I still get Oops with this patch for
> largepages. Please let me know, if you have a new version to try.
I'm going to throw this back over the wall at Adam and Dave Gibson. It
is going to take a bit more than a cosmetic fix. The complexity comes
because there are two _distinct_ hugetlb cases here. The first is when
the HPTE is condensed into the PMD like on normal i386 or in the !
64K_PAGES case on ppc64. The second is when the HPTE is stored like a
normal PTE in a PTE page like on the 64K_PAGES ppc64 case.
These need to be handled in two different places in the smaps pagetable
walk. Add that into the normal small PTE case and we end up having
_three_ cases to handle for the end of the pagetable walk.
Before we did faulting for these PTEs, it would have been easy to have a
if() to hack it in at the top of the pagetable walk, but we can't do
that any more.
The big question is: do we ever need to deal with large pages in a
normal pagetable walk? If not, we can probably just hack the two extra
cases in. How do we tell in generic code whether we're looking at a
real "huge PMD", or one that points to a PTE page with "huge PTE"s?
That seems to be a ppc64-specific question for now.
Badari, appended is a patch that doesn't fix the accounting in smaps,
but will simply skip the huge page vmas. It will at least keep you from
oopsing.
-- Dave
smaps-fix-dave/fs/proc/task_mmu.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -puN fs/proc/task_mmu.c~smaps_fix fs/proc/task_mmu.c
--- smaps-fix/fs/proc/task_mmu.c~smaps_fix 2005-12-12 13:19:05.000000000 -0800
+++ smaps-fix-dave/fs/proc/task_mmu.c 2005-12-12 13:21:07.000000000 -0800
@@ -289,7 +289,7 @@ static int show_smap(struct seq_file *m,
struct mem_size_stats mss;
memset(&mss, 0, sizeof mss);
- if (vma->vm_mm)
+ if (vma->vm_mm && !is_vm_hugetlb_page(vma))
smaps_pgd_range(vma, vma->vm_start, vma->vm_end, &mss);
return show_map_internal(m, v, &mss);
}
_
prev parent reply other threads:[~2005-12-12 21:28 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-07 22:37 2.6.15-rc4 panic in __nr_to_section() with CONFIG_SPARSEMEM Badari Pulavarty
2005-12-07 22:52 ` Dave Hansen
2005-12-07 23:05 ` Andy Whitcroft
2005-12-07 23:22 ` Badari Pulavarty
2005-12-07 23:34 ` Dave Hansen
2005-12-08 0:48 ` Dave Hansen
2005-12-08 16:07 ` Badari Pulavarty
2005-12-08 19:15 ` Dave Hansen
2005-12-08 19:33 ` Hugh Dickins
2005-12-08 19:47 ` Dave Hansen
2005-12-08 19:53 ` Badari Pulavarty
2005-12-08 23:48 ` David Gibson
2005-12-09 0:16 ` Dave Hansen
2005-12-12 16:19 ` Badari Pulavarty
2005-12-12 21:28 ` Dave Hansen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1134422889.27961.22.camel@localhost \
--to=haveblue@us.ibm.com \
--cc=agl@us.ibm.com \
--cc=andyw@uk.ibm.com \
--cc=dwg@au1.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pbadari@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox