Re: [Crash-utility] enhance bt command

On Mon, 2008-03-03 at 14:56 -0500, Dave Anderson wrote: > Ming Zhang wrote: >> On Mon, 2008-03-03 at 14:04 -0500, Dave Anderson wrote: >>> Ming Zhang wrote: >>> >>>> my English sucks... >>>> >>>> this is what i got. my side size-512 or size-1024 also works. just stuff >>>> like dentry cache or inode cache does not work. >>>> >>>> >>>> crash> rd 10078b2bca0 2 >>>> 10078b2bca0: 000001007877c8d4 00000100710fd5c8 ..wx.......q.... >>>> crash> rd -S 10078b2bca0 2 >>>> 10078b2bca0: [dentry_cache] 00000100710fd5c8 >>>> crash> kmem -s 10078b2bca0 >>>> kmem: address is not allocated in slab subsystem: 10078b2bca0 >>> No, your English is fine -- it's your command-entering that sucks! >>> >>> Above, when you entered "kmem -s 10078b2bca0", you're incorrectly entering >>> the *address* where the dentry_cache reference (1007877c8d4) is located. >>> And so it's telling you that 10078b2bca0 is not allocated in the slab >>> subsystem, which it isn't... >>> >>> But if you entered "kmem -s 1007877c8d4", you'd see the dentry_cache >>> information. >> yes. i noticed that. need some tea when handling 3 bugs at the same >> time... >> >> so here is my understanding. it actually shows the slab object that >> contain that address. it might not be the address of that object. so >> here is what i need to do >> >> crash> rd -x 10078b2bca0 >> 10078b2bca0: 000001007877c8d4 >> crash> rd -S 10078b2bca0 >> 10078b2bca0: [dentry_cache] >> >> crash> kmem -s 000001007877c8d4 >> CACHE NAME OBJSIZE ALLOCATED TOTAL >> SLABS SSIZE >> 10037ffc080 dentry_cache 240 9429 10560 >> 660 4k >> SLAB MEMORY TOTAL ALLOCATED FREE >> 1007877c040 1007877c088 16 9 7 >> FREE / [ALLOCATED] >> [1007877c8d4] >> >> this only tell me that it belongs to one dentry object, but no idea >> which one >> >> then i have to use kmem -S dentry_cache, find out this piece >> >> SLAB MEMORY TOTAL ALLOCATED FREE >> 1007877c040 1007877c088 16 9 7 >> FREE / [ALLOCATED] >> [1007877c088] >> [1007877c178] >> 1007877c268 (cpu 1 cache) >> 1007877c358 (cpu 1 cache) >> [1007877c448] >> 1007877c538 (cpu 1 cache) >> [1007877c628] >> [1007877c718] >> [1007877c808] >> ~~~~~~~~~~~~~~~~~~~~ then find out it is here. >> [1007877c8f8] >> 1007877c9e8 (cpu 1 cache) >> 1007877cad8 (cpu 1 cache) >> [1007877cbc8] >> [1007877ccb8] >> 1007877cda8 (cpu 1 cache) >> 1007877ce98 (cpu 1 cache) >> >> then i know the object contain this address is 1007877c808. >> then >> >> crash> dentry.d_iname >> struct dentry { >> [0xcc] unsigned char d_iname[36]; >> } >> crash> eval c808+cc >> hexadecimal: c8d4 >> decimal: 51412 >> octal: 144324 >> >> show me that variable in stack actually is d_iname. >> >> then can we have the output format as >> >> 10078b2bca0: [000001007877c808+cc: dentry_cache] >> >> so we know the object address, which slab it is in, and the offset, >> (thus can derive the raw value), all in one shot? >> > You've done a fine bit of debugging your issue... > > But I think that's a bit of overkill for each address reference. > > To do it right it would have to walk slab chains to gather all of the > information needed by the "kmem -S" output, which can be extremely > time-consuming, and potentially error-prone if the slab chain is > corrupt or being modified while running on a live system. full agree. realized now. then here is my question, how "kmem -s <addr>" find out which slab this address belong to? by only looking at the page?

then here is my revised suggestion. can we split this into 2 steps? (1) rd -S show [raw address: cache name] (this is a great to have since do rd 2 times, one with -S and another without -S is tedious.)

(2) and kmem -s <address> show which slab it is in and optionally (with a new option like -O) show the object?

(this is nice to have). thanks.