----- Original Message ----- > Dave, > > On Mon, Mar 25, 2013 at 2:27 AM, Dave Anderson <anderson@xxxxxxxxxx> > 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 -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
