[Crash-utility] kmem: WARNING: cannot find mem_map page for address

[Dave Anderson]

----- Original Message -----
> On 12/17/12 09:03, Dave Anderson wrote:
> >> That also removed the mysterious problem of having a duplicate
> >> error
> >> message show up on the console.
> > 
> > OK, if that works for you...
> 
> In the sense of being able to do my day job, yes.
> In the sense of aesthetics, not so much.
> 
> > Right -- I would never expect error() to be called while inside
> > an open_tmpfile() operation.  Normally the behind-the-scenes data
> > is parsed, and if anything is to be displayed while open_tmpfile()
> > is still in play, it would be fprint()'ed using pc->saved_fp.
> 
> I think the aesthetically pleasing solution is an "i_am_playing_with_tmpfile()"
> call that says it isn't closed and crash functions shouldn't be using it.
> Plus a parallel "i_am_done_with_tmpfile()" that gets implied by "close_tmpfile()".
> I can supply a patch, if you like.  Probably with less verbose function names.

If pc->tmpfile is non-NULL, then open_tmpfile() is in use.  What would be
the purpose of the extra functions?

> 
> >>> crash> gdb set $tp = (struct cfs_trace_page *)0xffff8807fb590740
> >>> crash> p $tp->page
> >>> $7 = (cfs_page_t *) 0xffffea001bb1d1e8
> >>> crash> p *$tp->page
> >>> $8 = {
> >>>   flags = 144115188075855872,
> >>>   _count = {
> >>>     counter = 1
> >>>   },
> >>> [...]
> >>>   lru = {
> >>>     next = 0xdead000000100100,
> >>>     prev = 0xdead000000200200
> >>>   }
> >>> }
> >>> crash> kmem 0xffffea001bb1d1e8
> >>> kmem: WARNING: cannot find mem_map page for address:
> >>> ffffea001bb1d1e8
> >>> 879b1d1e8: kernel virtual address not found in mem map
> >>
> >> So I can print out the page_t structure (renamed as cfs_page_t in
> >> Lustre)
> >> at address 0xffff8807fb590740, but when I try to get kmem
> >> information about
> >> it, it cannot find the  page.  What am I missing?
> >>
> >> Thanks for hints/pointers!  Regards, Bruce
> > 
> > I'm not sure, other than it doesn't seem to be able to find
> > ffffea001bb1d1e8
> 
> I was able to figure that out.  I also printed out the "kmem -v" table and
> sorted the result.  The result with "kmem -n"
> 
> [...]
> 66  ffff88087fffa420  ffffea0000000000  ffffea0007380000  2162688
> 67  ffff88087fffa430  ffffea0000000000  ffffea0007540000  2195456
> 132608  ffff88083c9bdb98  ffff88083c9bdd98  ffff8840e49bdd98  4345298944
> 132609  ffff88083c9bdba8  ffff88083c9796c0  ffff8840e4b396c0  4345331712
> ;...]
> 
> viz. it ain't there.  Which is quite interesting, because if the lustre
> cluster file system structure "cfs_trace_data" actually pointed off into
> unmapped memory, it would have fallen over long, long before the point
> where it did fall over.

I don't see the vmemmap range in the "kmem -v" output.  It is mapped
kernel memory, but AFAIK it's not kept in the kernel's "vmlist" list.
Do you see that range in your "kmem -v" output? 

> >>>> ffff8807fb590740
> >>>> struct cfs_trace_page {
> >>>>  page = 0xffffea001bb1d1e8,  <<<<==== address in question
> >>>>  linkage = {
> >>>>    next = 0xffff8807fb590ee8,
> >>>>    prev = 0xffff880824e3d810
> >>>>  },
> 
> It seems like it is both there and not there, so I am misunderstanding something.
> For sure.
> 
> > crash> whatis $tp->page
> > cfs_page_t *
> > crash> p $tp->page
> > $8 = (cfs_page_t *) 0xffffea001bb1d1e8
> > crash> p *$tp->page
> > $9 = {
> >   flags = 0x200000000000000,
> >   _count = {
> >     counter = 1
> >   },
> >   {
> >     _mapcount = {
> >       counter = -1
> >     },
> >     {
> >       inuse = 65535,
> >       objects = 65535
> >     }
> >   },
> >   {
> >     {
> >       private = 0,
> >       mapping = 0x0
> >     },
> >     ptl = {
> >       {
> >         rlock = {
> >           raw_lock = {
> >             slock = 0
> >           }
> >         }
> >       }
> >     },
> >     slab = 0x0,
> >     first_page = 0x0
> >   },
> >   {
> >     index = 0,
> >     freelist = 0x0,
> >     pfmemalloc = false
> >   },
> >   lru = {
> >     next = 0xdead000000100100,
> >     prev = 0xdead000000200200
> >   }
> > }
> 
> So clearly, I am able to read cfs_page_t data at that address.
> But I cannot get the mappings for it, and neither can my lustre
> extensions.  (We are trying to extract trace data from an in-kernel
> circular buffer that is 5,100 pages in size (20 Meg).)
> 
> Thank you any help at all!  Regards, Bruce

OK so you say you cannot get the mappings for it, but what 
does "vtop 0xffffea001bb1d1e8" show?

Dave