----- 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