On 28/12/06, Ingo Molnar <[EMAIL PROTECTED]> wrote:
* Catalin Marinas <[EMAIL PROTECTED]> wrote:
> >memleak info is at a negative offset from the allocated pointer. I.e.
> >that if kmalloc() returns 'ptr', the memleak info could be at
> >ptr-sizeof(memleak_info). That way you dont have to know
* Catalin Marinas <[EMAIL PROTECTED]> wrote:
> >memleak info is at a negative offset from the allocated pointer. I.e.
> >that if kmalloc() returns 'ptr', the memleak info could be at
> >ptr-sizeof(memleak_info). That way you dont have to know the size of the
> >object beforehand and there's absol
On 27/12/06, Ingo Molnar <[EMAIL PROTECTED]> wrote:
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> The pure per-CPU design would have to embedd the CPU ID the object is
> attached to into the allocated object. If that is not feasible then
> only the global hash remains i think.
embedding the info sh
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > As I mentioned in a different e-mail, a way to remove the global
> > hash table is to create per-cpu hashes. The only problem is that in
> > these 8-10% of the cases, freeing would need to look up the other
> > hashes. This would become a problem wi
On 27/12/06, Ingo Molnar <[EMAIL PROTECTED]> wrote:
* Catalin Marinas <[EMAIL PROTECTED]> wrote:
> On 17/12/06, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >it would be nice to record 1) the jiffies value at the time of
> >allocation, 2) the PID and the comm of the task that did the allocation.
>
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > Trying to copy the comm with get_task_comm, I get the lockdep report
> > below, caused by acquiring the task's alloc_lock. Any idea how to go
> > around this?
>
> just memcpy p->comm without any locking. It's for the current task,
> right? That doe
* Catalin Marinas <[EMAIL PROTECTED]> wrote:
> On 17/12/06, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >it would be nice to record 1) the jiffies value at the time of
> >allocation, 2) the PID and the comm of the task that did the allocation.
> >The jiffies timestamp would be useful to see the age
On 27/12/06, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
On Wed, 2006-12-27 at 16:14 +, Catalin Marinas wrote:
> On 17/12/06, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > it would be nice to record 1) the jiffies value at the time of
> > allocation, 2) the PID and the comm of the task that did
On Wed, 2006-12-27 at 16:14 +, Catalin Marinas wrote:
> On 17/12/06, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > it would be nice to record 1) the jiffies value at the time of
> > allocation, 2) the PID and the comm of the task that did the allocation.
> > The jiffies timestamp would be useful t
On 17/12/06, Ingo Molnar <[EMAIL PROTECTED]> wrote:
it would be nice to record 1) the jiffies value at the time of
allocation, 2) the PID and the comm of the task that did the allocation.
The jiffies timestamp would be useful to see the age of the allocation,
and the PID/comm is useful for contex
* Catalin Marinas <[EMAIL PROTECTED]> wrote:
> On 18/12/06, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >* Catalin Marinas <[EMAIL PROTECTED]> wrote:
> >> I could also use a simple allocator based on alloc_pages [...]
> >> [...] It could be so simple that it would never need to free any
> >> pages,
On 18/12/06, Ingo Molnar <[EMAIL PROTECTED]> wrote:
* Catalin Marinas <[EMAIL PROTECTED]> wrote:
> I could also use a simple allocator based on alloc_pages [...]
> [...] It could be so simple that it would never need to free any
> pages, just grow the size as required and reuse the freed memleak
On 18/12/06, Ingo Molnar <[EMAIL PROTECTED]> wrote:
* Catalin Marinas <[EMAIL PROTECTED]> wrote:
> >at freeing we only have to look up the tree belonging to object->cpu.
>
> At freeing, kmemleak only gets a pointer value which has to be looked
> up in the hash table for the corresponding memlea
* Catalin Marinas <[EMAIL PROTECTED]> wrote:
> >at freeing we only have to look up the tree belonging to object->cpu.
>
> At freeing, kmemleak only gets a pointer value which has to be looked
> up in the hash table for the corresponding memleak_object. Only after
> that, we can know memleak_ob
On 18/12/06, Ingo Molnar <[EMAIL PROTECTED]> wrote:
* Catalin Marinas <[EMAIL PROTECTED]> wrote:
> >> [...] It could be so simple that it would never need to free any
> >> pages, just grow the size as required and reuse the freed memleak
> >> objects from a list.
> >
> >sounds good to me. Pleas
* Catalin Marinas <[EMAIL PROTECTED]> wrote:
> >> [...] It could be so simple that it would never need to free any
> >> pages, just grow the size as required and reuse the freed memleak
> >> objects from a list.
> >
> >sounds good to me. Please make it a per-CPU pool.
>
> Isn't there a risk for
On 18/12/06, Ingo Molnar <[EMAIL PROTECTED]> wrote:
* Catalin Marinas <[EMAIL PROTECTED]> wrote:
> I could also use a simple allocator based on alloc_pages since
> kmemleak doesn't track pages. [...]
actually, i'm quite sure we want to track pages later on too, any reason
why kmemleak shouldnt
* Catalin Marinas <[EMAIL PROTECTED]> wrote:
> > hm, even on vanilla you might run into problems in slab_destroy(),
> > there we hold the l3 lock.
>
> It seems that slab_destroy doesn't take the l3 lock again if it is
> already held, otherwise it would fail without kmemleak. However, I
> can'
On 17/12/06, Ingo Molnar <[EMAIL PROTECTED]> wrote:
* Catalin Marinas <[EMAIL PROTECTED]> wrote:
> Do you need these fixes to avoid a compiler error? If yes, this is
> caused by a bug in gcc-4.x. The kmemleak container_of macro has
> protection for non-constant offsets passed to container_of but
* Catalin Marinas <[EMAIL PROTECTED]> wrote:
> On 17/12/06, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >one more thing: after bootup i need to access the /debug/memleak file
> >twice to get any output from it - is that normal? The first 'cat
> >/debug/memleak' gives no output (but there's the usu
On 17/12/06, Ingo Molnar <[EMAIL PROTECTED]> wrote:
it would also be nice to have more information than this:
unreferenced object 0xf76f5af8 (size 512):
[] memleak_alloc
[] kmem_cache_zalloc
[] probe_hwif
[] probe_hwif_init_with_fixup
[] ide_setup_pci_device
[] amd74xx_probe
[] i
On 17/12/06, Ingo Molnar <[EMAIL PROTECTED]> wrote:
one more thing: after bootup i need to access the /debug/memleak file
twice to get any output from it - is that normal? The first 'cat
/debug/memleak' gives no output (but there's the usual scanning delay,
so memleak does do its work).
Yes, th
On Sun, 2006-12-17 at 09:58 +0100, Ingo Molnar wrote:
> * Catalin Marinas <[EMAIL PROTECTED]> wrote:
>
> > Hi Ingo,
> >
> > On 16/12/06, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > >FYI, i'm working on integrating kmemleak into -rt. Firstly, i needed the
> > >fixes below when applying it ontop of
plus a boot-time and a runtime switch to turn kmemleak off would be nice
as well. (turning it back on is probably not needed and is harder as
well)
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
it would also be nice to have more information than this:
unreferenced object 0xf76f5af8 (size 512):
[] memleak_alloc
[] kmem_cache_zalloc
[] probe_hwif
[] probe_hwif_init_with_fixup
[] ide_setup_pci_device
[] amd74xx_probe
[] ide_scan_pcidev
[] ide_scan_pcibus
[] ide_init
[]
one more thing: after bootup i need to access the /debug/memleak file
twice to get any output from it - is that normal? The first 'cat
/debug/memleak' gives no output (but there's the usual scanning delay,
so memleak does do its work).
Ingo
-
To unsubscribe from this list: send the lin
the other thing that is pretty ugly is the recursive_enter/clear/exit
code. I'd suggest the lockdep model here: use a single flag in
task_struct to detect recursion. Also, never use BUG() when hitting a
bug in a debugging helper - that will crash the box. Use a flag to turn
off the whole thing
* Catalin Marinas <[EMAIL PROTECTED]> wrote:
> Hi Ingo,
>
> On 16/12/06, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >FYI, i'm working on integrating kmemleak into -rt. Firstly, i needed the
> >fixes below when applying it ontop of 2.6.19-rt15.
>
> Do you need these fixes to avoid a compiler error
Hi Ingo,
On 16/12/06, Ingo Molnar <[EMAIL PROTECTED]> wrote:
FYI, i'm working on integrating kmemleak into -rt. Firstly, i needed the
fixes below when applying it ontop of 2.6.19-rt15.
Do you need these fixes to avoid a compiler error? If yes, this is
caused by a bug in gcc-4.x. The kmemleak c
* Catalin Marinas <[EMAIL PROTECTED]> wrote:
> This series of patches represent version 0.13 of the kernel memory
> leak detector. See the Documentation/kmemleak.txt file for a more
> detailed description. The patches are downloadable from (the whole
> patch or the broken-out series) http://ww
This series of patches represent version 0.13 of the kernel memory
leak detector. See the Documentation/kmemleak.txt file for a more
detailed description. The patches are downloadable from (the whole
patch or the broken-out series) http://www.procode.org/kmemleak/
What's new in this version:
- up
31 matches
Mail list logo
