[Crash-utility] enhance bt command

[Dave Anderson]

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