[Crash-utility] How to parse out kmem output?

[Dave Anderson]

----- Original Message -----
> Dave,
> 
> On Mon, Mar 25, 2013 at 2:27 AM, Dave Anderson <anderson at redhat.com>
> wrote:
> >
> >
> > ----- Original Message -----
> >>
> >>
> >> ----- Original Message -----
> >> > Hi list,
> >> >
> >> > I am current tracking one issue related with memory.
> >> > What I want to know if a kernel address which is alloced by kmalloc,
> >> > 1. whether that address is already freed or not
> >
> > I should also have mentioned that the address you are looking for could
> > have been previously allocated, freed, and now it's part of the kmalloc-2048
> > slab cache where it hasn't been re-allocated yet?  It's hard to tell, but
> > it doesn't seem to be currently-in-use.
> >
> >> > 2. if not freed, could I know which task or struct is owning that range?
> >
> > The owner is not tracked by the SLAB/SLUB subsystem, at least not unless
> > some type of DEBUG is turned on.  You might try doing a "search" for the
> > address, and if found, try to determine what the containing addresses
> > are.
> 
> I see, thanks for the detailed explanation!
> 
> >
> > Dave
> >
> >> >
> >> > I am also try to use the kmem command to get more info,
> >> > but I don't know the meaning for its output...
> >> > Like "CACHE"/"ALLOCATED"/"TOTAL"/"SLABS" member,
> >>
> >> The CACHE is the kmem_cache structure address.
> >> The ALLOCATED total is the number of objects that have been allocated from the CACHE.
> >> The TOTAL is the maximum number of objects in the CACHE.
> >> The SLABS is the number of of SSIZE-sized slabs that are current being used
> >> to create the TOTAL number of objects.
> >>
> >> > what are they referring to?
> >> > And according to "FREE / [ALLOCATED]" as below, does it
> >> > mean that 0xe1416acc already be freed?
> >> >
> >> > crash> kmem -S 0xe1416acc
> >> > CACHE    NAME                 OBJSIZE  ALLOCATED     TOTAL
> >> >  SLABS
> >> >  SSIZE
> >> > e0002400 kmalloc-2048            2048        156       160
> >> >     10
> >> >    32k
> >> >   SLAB      MEMORY    NODE  TOTAL  ALLOCATED  FREE
> >> >   c1628200  e1410000     0     12         12     0
> >> >   FREE / [ALLOCATED]
> >> >   [e1410000]
> >> >   [e1410800]
> >> >   [e1411000]
> >> >   [e1411800]
> >> >    e1412000  (cpu 0 cache)
> >> >    e1412800  (cpu 0 cache)
> >> >    e1413000  (cpu 0 cache)
> >> >    e1413800  (cpu 0 cache)
> >> >    e1414000  (cpu 0 cache)
> >> >    e1414800  (cpu 0 cache)
> >> >    e1415000  (cpu 0 cache)
> >> >   [e1415800]
> >> > crash>
> >>
> >> The SLUB display indicates that there are 12 objects allocated
> >> from the "kmalloc-2048" cache, and either they are currently
> >> in use, or they are sitting on the cpu 0 per-cpu cache.  The
> >> address that you entered would "fit" into the 32k slab page,
> >> but it doesn't seem to be allocated or sitting in the cpu 0 cache.
> >>
> >> I believe that means that the object is currently free.
> >>
> >> > Also seems current kmem only support SLAB, right?
> >>
> >> Wait, isn't your kernel CONFIG_SLUB?  Enter "help -v" and look
> >> at the flags field.  It will show either KMALLOC_SLUB or KMALLOC_SLAB.
> >> CONFIG_SLOB is not supported.
> 
> It just shows KMALLOC_SLUB, is that ok?

"help -v" will show either KMALLOC_SLUB or KMALLOC_SLAB -- depending upon
whether your kernel was configured with CONFIG_SLUB or CONFIG_SLAB.

If your kernel was configured with CONFIG_SLOB -- which the crash
utility does not support -- then neither will be shown.

Dave