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

[Lei Wen]

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?

Thanks,
Lei

>>
>> Dave
>>
>>
>> > If memory is allocated with like SLUB or SLOB, could the kmem
>> > still handle it?
>> >
>> > Thanks,
>> > Lei
>> >
>> > --
>> > Crash-utility mailing list
>> > Crash-utility at redhat.com
>> > https://www.redhat.com/mailman/listinfo/crash-utility
>> >
>>
>> --
>> Crash-utility mailing list
>> Crash-utility at redhat.com
>> https://www.redhat.com/mailman/listinfo/crash-utility
>>
>
> --
> Crash-utility mailing list
> Crash-utility at redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility