[Crash-utility] enhance bt command

[Ming Zhang]

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.



> 
> Dave
-- 
Ming Zhang


@#$%^ purging memory... (*!%
http://blackmagic02881.wordpress.com/
http://www.linkedin.com/in/blackmagic02881
--------------------------------------------