[Crash-utility] crash-4.0-2.10 ppc64 4-level pagetable fixes

[Badari Pulavarty]

On Tue, 2005-11-08 at 14:17 -0500, Dave Anderson wrote:
> Badari Pulavarty wrote: 
> > Hi Dave, 
> > 
> > Here are the fixes to make crash understand PPC64 4-level pagetable 
> > layout. 
> > 
> > I am not a PPC64 expert, I coded up looking at the ppc64 kernel 
> > pagetable handling code. It seems to work fine for most part. 
> > 
> > But I do get occasional, "user virtual" translation failures. 
> > I think I screwed up PMD calculations. I am not able to spot 
> > the problem. Can some one help ? 
> > 
> > Thanks, 
> > Badari
> > 
> It's possible that the virtual address that you're examining 
> is not backed by physical memory (yet).  If you do a "vtop" 
> on the address that gives you the error, you may see it's 
> simply not mapped. 
> 
> For example, I created a little program call "bogus" that 
> does a malloc of 1000000, prints the beginning address 
> of the region, and then pauses: 
> 
> main() 
> { 
>         char *buf; 
> 
>         buf = malloc(1000000); 
>         printf("buf: %lx\n", buf); 
>         pause(); 
> } 
> 
> When I run it, it prints "buf: 2a95586010".  If I look at 
> it with crash, the first page of data is instantiated, i.e. 
> it was already in place before the malloc() call, but if 
> I go to any page beyond that, it does this: 
> 
> crash> set 13474 
>     PID: 13474 
> COMMAND: "bogus" 
>    TASK: 100310f57f0  [THREAD_INFO: 10005394000] 
>     CPU: 1 
>   STATE: TASK_INTERRUPTIBLE 
> crash> rd 2a95586010 
>       2a95586010:  0000000000000000                    ........ 
> crash> rd 2a95587010 
> rd: invalid user virtual address: 2a95587010  type: "64-bit UVADDR" 
> crash> vtop 2a95587010 
> VIRTUAL     PHYSICAL 
> 2a95587010  (not mapped) 
> 
>    PGD: 279cb550 => 365fa067 
>    PMD: 365fa550 => 27ce6067 
>    PTE: 27ce6c38 => 0 
> 
>       VMA           START       END     FLAGS FILE 
>   1003c5898d8    2a95584000 2a9567c000 100073 
> 
> crash> 

Yep. You are right, those pages are not mapped. Initially
I thought that was the case, but I wasn't really sure if it
can happen with segments from shared libraries. (since 
the routine which is telling its not mapped involves 
going through my code).

Anyway, I verified this on x86-64 machine also - I do
get "read" error and those pages are not mapped.

I guess, my changes are good :)

Haren, can you review them ?

Thanks,
Badari

crash> rd -u 400002d6000
rd: invalid user virtual address: 400002d6000  type: "64-bit UVADDR"
crash> vtop 400002d6000
VIRTUAL           PHYSICAL
400002d6000       (not mapped)

PAGE DIRECTORY: c000000088ed5000
  L4: c000000088ed5400 => c0000000e8efa800
  PGD: c0000000e8efa800 => c0000000e8efac00
  PMD: c0000000e8efac08 => c00000008cfff000
  PMD: c0000000e8efac08 => c00000008cfff6b0
  PTE: c00000008cfff6b0 => 0

      VMA              START             END        FLAGS FILE
c0000000eb66a140      400002d6000      400002e5000
70 /lib64/tls/libc.so.6

FILE: /lib64/tls/libc.so.6  OFFSET: 141000