All of lore.kernel.org
 help / color / mirror / Atom feed
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);
 }
_



      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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.