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