[Crash-utility] enhance bt command

[Ming Zhang]

On Mon, 2008-03-03 at 15:35 -0500, Dave Anderson wrote:

<snip>

> >>>
> >>> 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?
> 
> The kmem_cache and containing slab addresses are stashed in unused
> fields of the page structure of the object's virtual address.

ic. good to know this.


> 
> > 
> > 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.)
> 
> But in your case, for example, I'm presuming you've done a "bt -f",
> and simply would like a symbols/slab translation of a chunk of memory
> making up one of the stack frames, so you do a subsequent "rd -S" of
> that memory area.  Doesn't seem that tedious to me...

have to agree.


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

i emphasize on "and optionally...", ;)


> And if you're asking whether the object can be dumped as the structure
> type it is (?), well, how would it be possible from the crash utility's
> viewpoint to even know what type of data structure it is?

no. what i mean is kmem -s <address> does not give me the object address

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]


i still have to use kmem -S to find out 1007877c808 is the object that
contain this address. nice if crash can do this for me.


> 
> If you want to look at all of the objects in a slab represented
> as data structures, you're going to have supply the knowledge of
> what data structure they are.  It's simple enough, just do a "kmem -S"
> into a file, delete everything except the object addresses that you're
> interested in, insert "struct whatever" in front of each address, save

this is exactly what i did when i have to do work like this by using
gawk, tr, and grep.

> the file -- and run it as crash input file.
> 

how to do this? i know crash -i can run a file at beginning. but how to
run command in a file at any moment?




> > 
> > (this is nice to have).
> > 
> > thanks.
> 
> Look, you can have it do anything you want...
> 
> However, keep in mind that there are 4 diffenent kmem slab paradigms
> supported (the "original", the first verion with per-cpu objects, the
> second version with per-cpu objects, and now the completely new CONFIG_SLUB
> subsystem).  All of them would have to be supported.  And the code that does
> the object dumping is somewhat replicated and embedded in the "kmem -S" support
> code, so it's not a simple re-use of an existing function, which I've done
> to get the simple "rd -S" output.


ic.


> 
> Dave
> 
-- 
Ming Zhang


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