Re: [Crash-utility] How to parse out kmem output?
----- 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.
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.
Dave
> If memory is allocated with like SLUB or SLOB, could the kmem
> still handle it?
>
> Thanks,
> Lei
>
> --
> Crash-utility mailing list
> Crash-utility(a)redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
>
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility