Re: [Crash-utility] enhance bt command

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.

Dave