From: Matt Mackall On Thu, Dec 20, 2007 at 04:17:26PM -0800, David Miller wrote: > From: Mariusz Kozlowski > Date: Thu, 20 Dec 2007 20:47:55 +0100 > > > [ 145.128915] TSTATE: 0000004411009603 TPC: 00000000005119ac TNPC: 00000000005119b0 Y: 00000000 Not tainted > > [ 145.128940] TPC: > > My suspicion at this point is that with certain RAM layouts, simply > iterating over PFN's is simply not working out. That was my original suspicion, which is why I asked Mariusz to effectively comment out the actual PFN lookup up-thread. I didn't send him a patch to do that, so I guess my instructions on how to hack it may have been misunderstood. > pfn_to_page() seems to be doing no range checking, and with sparsemem > vmemmap, which sparc64 always uses, this can be problematic. > > It just blindly goes "vmemmap + pfn" which is asking for trouble, in > particular when the physical RAM layout really is sparse. > > Maybe it's enough to add a pfn_valid() check here? If pfn_valid() > means there is a vmemmap translation setup for that page struct too, > it would work. Here's a test patch: Cc: Mariusz Kozlowski Cc: David Miller Signed-off-by: Andrew Morton --- fs/proc/proc_misc.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff -puN fs/proc/proc_misc.c~maps4-add-proc-kpageflags-interface-fix-2 fs/proc/proc_misc.c --- a/fs/proc/proc_misc.c~maps4-add-proc-kpageflags-interface-fix-2 +++ a/fs/proc/proc_misc.c @@ -699,7 +699,10 @@ static ssize_t kpagecount_read(struct fi return -EIO; while (count > 0) { - ppage = pfn_to_page(pfn++); + ppage = 0; + if (pfn_valid(pfn)) + ppage = pfn_to_page(pfn); + pfn++; if (!ppage) pcount = 0; else @@ -762,7 +765,10 @@ static ssize_t kpageflags_read(struct fi return -EIO; while (count > 0) { - ppage = pfn_to_page(pfn++); + ppage = 0; + if (pfn_valid(pfn)) + ppage = pfn_to_page(pfn); + pfn++; if (!ppage) kflags = 0; else _