Hello,
> > > [ 145.128915] TSTATE: 0000004411009603 TPC: 00000000005119ac TNPC: 00000000005119b0 Y: 00000000 Not tainted
> > > [ 145.128940] TPC: <kpagecount_read+0x94/0xe0>
> >
> > 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.
No. I just made a trivial mistake :-/ Sorry for confusion. I guess I need to
verify things three times before sending an email next time.
> > 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:
Tested on 2.6.23 and 2.6.24-rc5-mm1. The patch fixes the bug.
Thanks a lot to both of you.
Mariusz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
