----- 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@xxxxxxxxxx > > https://www.redhat.com/mailman/listinfo/crash-utility > > > > -- > Crash-utility mailing list > Crash-utility@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/crash-utility > -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
