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

[Badari Pulavarty]

On Wed, 2005-11-09 at 08:45 -0500, Dave Anderson wrote:
> Haren Myneni wrote: 
> >   
> > 
> > crash-utility-bounces at redhat.com wrote on 11/08/2005 02:54:33 PM: 
> > 
> > > On Tue, 2005-11-08 at 17:32 -0500, Dave Anderson wrote: 
> > > > Badari Pulavarty wrote: 
> > > > 
> > > > > On Tue, 2005-11-08 at 14:42 -0500, Dave Anderson wrote: 
> > > > > > Badari Pulavarty wrote: 
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 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 
> > > > > > > 
> > > > > > 
> > > > > > The patch looks just fine to me -- the only minor things to 
> > > > > > add is a dump of the VM_ORIG/VM_4_LEVEL bits in 
> > > > > > the ppc64_dump_machdep_table() debug function, and 
> > > > > > although the "pud_clear_bad" is in all probability quite 
> > > > > > suitable as a qualifier, it's probably also worth adding 
> > > > > > an optional "--machdep vm=xxx" command line argument 
> > > > > > like I put in place for the x86_64 equivalent.  Just to
> > cover 
> > > > > > our collective arse... 
> > > > > > 
> > > > > > Anyway, upon Haren's blessing, it's good to go. 
> > > > > > 
> > > > > > Again -- really nice work! 
> > > > > 
> > > > > Okay, made recommended changes. 
> > > > > 
> > > > > I still need to figure out a decent symbol to identify 
> > > > > 4-level pagetable layout. I am looking through "nm -Bn". 
> > > > > I still can't find a decent one. (has to be some symbol 
> > > > > added for 2.6.14). 
> > > > > 
> > > > > Any ideas ? 
> > > > > 
> > > > 
> > > > If you can google out the wholesale patch that introduced the 
> > > > 4-level pagetable support, you might find something added 
> > > > or removed?  That's what I did for the x86_64 qualifier. 
> > > > 
> > > 
> > > Okay. I found new structure "pgtable_cache" got added along 
> > > with 4-level pagetable changes. I am using that symbol now. 
> > > 
> > > Thanks, 
> > > Badari 
> > > 
> > Badari, Thanks a lot for helping us on PPC64. 
> > 
> > Dave, Is it a problem if we use Linux version to determine 4-level
> > page table changes instead of looking for some symbol which might
> > get changed later. We need to make some more changes for 64K page
> > support added in 2.6.14-git11. 
> >  
> > 
> Maybe -- maybe not... 
> 
> It's kind of a chicken-and-egg situation, where the first readmem() 
> needs the virtual address range stuff to be in place, but we need 
> something out of the kernel data space to determine the virtual 
> address space range data.  That being said, it looks possible, at 
> least in the case of ppc64, that perhaps we could get away with 
> doing a readmem() of a unity-mapped address, since at the 
> point where the VM-range decision is made, machdep->kvbase 
> has just been set.  (Follow the readmem() path, and you'll see 
> what I mean...)  But you'd have to read raw data and muck 
> your way through it because the embedded gdb hasn't been 
> invoked yet.  Badari had asked the same thing earlier, about 
> using the THIS_KERNEL_VERSION macro, but again, the 
> underlying crash data to satisfy the macro doesn't get initialized 
> until after gdb is alive. 

Yes. You are right. I verified that THIS_KERNEL_VERSION is not
set at PRE_GDB time. 

What I am not sure is, how late we can push finding out 
if we have 4-level pagetables are not and still make
crash function.

Thanks,
Badari