linux-next: manual merge of the kmemleak tree

linux-next: manual merge of the kmemleak tree

[Stephen Rothwell]

Hi Catalin,

Today's linux-next merge of the kmemleak tree got a conflict in mm/slub.c
between commit 18fd427debcf37c06917b55295df682fd05fee76 ("slub: add hooks
for kmemcheck") from the kmemcheck tree and commit
64ea489328c2f450fb4dca49b9a33d1b2ddf0248 ("kmemleak: Add the slub memory
allocation/freeing hooks") from the kmemleak tree.

Just simple overlapping additions.  I fixed it up (see below) and can
carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --cc mm/slub.c
index 3f6953d,13543f5..0000000
--- a/mm/slub.c
+++ b/mm/slub.c
@@@ -16,9 -16,9 +16,10 @@@
  #include <linux/slab.h>
  #include <linux/proc_fs.h>
  #include <linux/seq_file.h>
 +#include <trace/kmemtrace.h>
  #include <linux/cpu.h>
  #include <linux/cpuset.h>
+ #include <linux/kmemleak.h>
  #include <linux/mempolicy.h>
  #include <linux/ctype.h>
  #include <linux/debugobjects.h>
@@@ -143,10 -142,10 +144,10 @@@
   * Set of flags that will prevent slab merging
   */
  #define SLUB_NEVER_MERGE (SLAB_RED_ZONE | SLAB_POISON | SLAB_STORE_USER | \
- 		SLAB_TRACE | SLAB_DESTROY_BY_RCU)
+ 		SLAB_TRACE | SLAB_DESTROY_BY_RCU | SLAB_NOLEAKTRACE)
  
  #define SLUB_MERGE_SAME (SLAB_DEBUG_FREE | SLAB_RECLAIM_ACCOUNT | \
 -		SLAB_CACHE_DMA)
 +		SLAB_CACHE_DMA | SLAB_NOTRACK)
  
  #ifndef ARCH_KMALLOC_MINALIGN
  #define ARCH_KMALLOC_MINALIGN __alignof__(unsigned long long)
@@@ -1630,7 -1619,7 +1631,8 @@@ static __always_inline void *slab_alloc
  	if (unlikely((gfpflags & __GFP_ZERO) && object))
  		memset(object, 0, objsize);
  
 +	kmemcheck_slab_alloc(s, gfpflags, object, c->objsize);
+ 	kmemleak_alloc_recursive(object, objsize, 1, s->flags, gfpflags);
  	return object;
  }
  
@@@ -1761,9 -1722,9 +1763,10 @@@ static __always_inline void slab_free(s
  	struct kmem_cache_cpu *c;
  	unsigned long flags;
  
+ 	kmemleak_free_recursive(x, s->flags);
  	local_irq_save(flags);
  	c = get_cpu_slab(s, smp_processor_id());
 +	kmemcheck_slab_free(s, object, c->objsize);
  	debug_check_no_locks_freed(object, c->objsize);
  	if (!(s->flags & SLAB_DEBUG_OBJECTS))
  		debug_check_no_obj_freed(object, s->objsize);

linux-next: manual merge of the kmemleak tree

[Stephen Rothwell]

Hi Catalin,

Today's linux-next merge of the kmemleak tree got a conflict in
init/main.c between commit b9ce08c01020eb28bfbfa6faf1c740281c5f418e
("kmemtrace: Core implementation") from the ftrace tree and commit
faff141a1eb4e690c0c54ab8684f8b267bc116c5 ("kmemleak: Add the base
support") from the kmemleak tree.

Trivial overlapping additions.  I fixed it up (see below) and can carry
the fix as necessary.  The only doubt in my mind was the ordering of
these calls.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --cc init/main.c
index ff3d580,c7f81aa..0000000
--- a/init/main.c
+++ b/init/main.c
@@@ -650,7 -643,7 +652,8 @@@ asmlinkage void __init start_kernel(voi
  	enable_debug_pagealloc();
  	cpu_hotplug_init();
  	kmem_cache_init();
 +	kmemtrace_init();
+ 	kmemleak_init();
  	debug_objects_mem_init();
  	idr_init_cache();
  	setup_per_cpu_pageset();

linux-next: manual merge of the kmemleak tree

[Stephen Rothwell]

Hi Catalin,

Today's linux-next merge of the kmemleak tree got a conflict in mm/slab.c
between commit 30532cb3c49a2a9fed94127aab26003c52398a51 ("slab: add hooks
for kmemcheck") from the kmemcheck tree and commit
26e73e5a681dc8268bd3fbcb3c26f4ac9fdc8433 ("kmemleak: Add the slab memory
allocation/freeing hooks") from the kmemleak tree.

I fixed it up (see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --cc mm/slab.c
index dffbac3,8e7c952..0000000
--- a/mm/slab.c
+++ b/mm/slab.c
@@@ -179,13 -178,13 +180,13 @@@
  			 SLAB_STORE_USER | \
  			 SLAB_RECLAIM_ACCOUNT | SLAB_PANIC | \
  			 SLAB_DESTROY_BY_RCU | SLAB_MEM_SPREAD | \
- 			 SLAB_DEBUG_OBJECTS | SLAB_NOTRACK)
 -			 SLAB_DEBUG_OBJECTS | SLAB_NOLEAKTRACE)
++			 SLAB_DEBUG_OBJECTS | SLAB_NOTRACK | SLAB_NOLEAKTRACE)
  #else
  # define CREATE_MASK	(SLAB_HWCACHE_ALIGN | \
  			 SLAB_CACHE_DMA | \
  			 SLAB_RECLAIM_ACCOUNT | SLAB_PANIC | \
  			 SLAB_DESTROY_BY_RCU | SLAB_MEM_SPREAD | \
- 			 SLAB_DEBUG_OBJECTS | SLAB_NOTRACK)
 -			 SLAB_DEBUG_OBJECTS | SLAB_NOLEAKTRACE)
++			 SLAB_DEBUG_OBJECTS | SLAB_NOTRACK | SLAB_NOLEAKTRACE)
  #endif
  
  /*
@@@ -3285,10 -3372,9 +3308,12 @@@ __cache_alloc_node(struct kmem_cache *c
    out:
  	local_irq_restore(save_flags);
  	ptr = cache_alloc_debugcheck_after(cachep, flags, ptr, caller);
+ 	kmemleak_alloc_recursive(ptr, obj_size(cachep), 1, cachep->flags,
+ 				 flags);
  
 +	if (likely(ptr))
 +		kmemcheck_slab_alloc(cachep, flags, ptr, obj_size(cachep));
 +
  	if (unlikely((flags & __GFP_ZERO) && ptr))
  		memset(ptr, 0, obj_size(cachep));
  
@@@ -3341,11 -3427,10 +3366,13 @@@ __cache_alloc(struct kmem_cache *cachep
  	objp = __do_cache_alloc(cachep, flags);
  	local_irq_restore(save_flags);
  	objp = cache_alloc_debugcheck_after(cachep, flags, objp, caller);
+ 	kmemleak_alloc_recursive(objp, obj_size(cachep), 1, cachep->flags,
+ 				 flags);
  	prefetchw(objp);
  
 +	if (likely(objp))
 +		kmemcheck_slab_alloc(cachep, flags, objp, obj_size(cachep));
 +
  	if (unlikely((flags & __GFP_ZERO) && objp))
  		memset(objp, 0, obj_size(cachep));
  
@@@ -3459,10 -3544,9 +3486,11 @@@ static inline void __cache_free(struct 
  	struct array_cache *ac = cpu_cache_get(cachep);
  
  	check_irq_off();
+ 	kmemleak_free_recursive(objp, cachep->flags);
  	objp = cache_free_debugcheck(cachep, objp, __builtin_return_address(0));
  
 +	kmemcheck_slab_free(cachep, objp, obj_size(cachep));
 +
  	/*
  	 * Skip calling cache_free_alien() when the platform is not numa.
  	 * This will avoid cache misses that happen while accessing slabp (which

linux-next: manual merge of the kmemleak tree

[Stephen Rothwell]

Hi Catalin,

Today's linux-next merge of the kmemleak tree got a conflict in
include/linux/slab.h between commit
e6df1035b1b488cafde1e69f1a25f2706c3ac1f7 ("kmemcheck: add mm functions")
from the kmemcheck tree and commit
26e73e5a681dc8268bd3fbcb3c26f4ac9fdc8433 ("kmemleak: Add the slab memory
allocation/freeing hooks") from the kmemleak tree.

Overlapping additions.  I fixed it up (see below) and can carry the fix
as necessary.  On the assumption that these definitions should use unique
bits, I used the next bit for SLAB_NOLEAKTRACE.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --cc include/linux/slab.h
index 2421246,05754ec..0000000
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@@ -62,13 -62,8 +62,15 @@@
  # define SLAB_DEBUG_OBJECTS	0x00000000UL
  #endif
  
 -#define SLAB_NOLEAKTRACE	0x00800000UL	/* Avoid kmemleak tracing */
 +/* Don't track use of uninitialized memory */
 +#ifdef CONFIG_KMEMCHECK
 +# define SLAB_NOTRACK		0x00800000UL
 +#else
 +# define SLAB_NOTRACK		0x00000000UL
 +#endif
 +
++#define SLAB_NOLEAKTRACE	0x01000000UL	/* Avoid kmemleak tracing */
+ 
  /* The following flags affect the page allocator grouping pages by mobility */
  #define SLAB_RECLAIM_ACCOUNT	0x00020000UL		/* Objects are reclaimable */
  #define SLAB_TEMPORARY		SLAB_RECLAIM_ACCOUNT	/* Objects are short-lived */

linux-next: manual merge of the kmemleak tree

[Stephen Rothwell]

Hi Catalin,

Today's linux-next merge of the kmemleak tree got a conflict in mm/slob.c
between commit 3eae2cb24a96509e0a38cc48dc1538a2826f4e33 ("kmemtrace: SLOB
hooks") from the ftrace tree and commit
19f8f253a808d317d34ccbbad3b15a1a8d2ac444 ("kmemleak: Add the slob memory
allocation/freeing hooks") from the kmemleak tree.

I fixed it up (see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --cc mm/slob.c
index 4d1c0fc,30b870f..0000000
--- a/mm/slob.c
+++ b/mm/slob.c
@@@ -489,12 -482,9 +490,13 @@@ void *__kmalloc_node(size_t size, gfp_
  			page = virt_to_page(ret);
  			page->private = size;
  		}
 +
 +		kmemtrace_mark_alloc_node(KMEMTRACE_TYPE_KMALLOC,
 +					  _RET_IP_, ret,
 +					  size, PAGE_SIZE << order, gfp, node);
  	}
  
+ 	kmemleak_alloc(ret, size, 1, gfp);
  	return ret;
  }
  EXPORT_SYMBOL(__kmalloc_node);

Re: linux-next: manual merge of the kmemleak tree

[Eduard - Gabriel Munteanu]

On Thu, Jan 15, 2009 at 04:27:17PM +1100, Stephen Rothwell wrote:
> Hi Catalin,
> 
> Today's linux-next merge of the kmemleak tree got a conflict in mm/slob.c
> between commit 3eae2cb24a96509e0a38cc48dc1538a2826f4e33 ("kmemtrace: SLOB
> hooks") from the ftrace tree and commit
> 19f8f253a808d317d34ccbbad3b15a1a8d2ac444 ("kmemleak: Add the slob memory
> allocation/freeing hooks") from the kmemleak tree.
> 
> I fixed it up (see below) and can carry the fix as necessary.
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
> 
> diff --cc mm/slob.c
> index 4d1c0fc,30b870f..0000000
> --- a/mm/slob.c
> +++ b/mm/slob.c
> @@@ -489,12 -482,9 +490,13 @@@ void *__kmalloc_node(size_t size, gfp_
>   			page = virt_to_page(ret);
>   			page->private = size;
>   		}
>  +
>  +		kmemtrace_mark_alloc_node(KMEMTRACE_TYPE_KMALLOC,
>  +					  _RET_IP_, ret,
>  +					  size, PAGE_SIZE << order, gfp, node);
>   	}
>   
> + 	kmemleak_alloc(ret, size, 1, gfp);
>   	return ret;
>   }
>   EXPORT_SYMBOL(__kmalloc_node);

Hi,

Perhaps kmemleak could attach to the kmemtrace traces. I'm currently
working on moving kmemtrace w/ ftrace to tracepoints instead of markers,
it'll hit the list soon. We'll use generic names for tracepoints, like
trace_kmalloc_node(). If this sounds okay, tell me and I'll relocate the
tracepoints definitions to a slab heades. All you'll need to do is
attach to probes using register_trace_*(), same as kmemtrace does.


	Cheers,
	Eduard

Re: linux-next: manual merge of the kmemleak tree

[Ingo Molnar]

* Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro> wrote:

> On Thu, Jan 15, 2009 at 04:27:17PM +1100, Stephen Rothwell wrote:
> > Hi Catalin,
> > 
> > Today's linux-next merge of the kmemleak tree got a conflict in mm/slob.c
> > between commit 3eae2cb24a96509e0a38cc48dc1538a2826f4e33 ("kmemtrace: SLOB
> > hooks") from the ftrace tree and commit
> > 19f8f253a808d317d34ccbbad3b15a1a8d2ac444 ("kmemleak: Add the slob memory
> > allocation/freeing hooks") from the kmemleak tree.
> > 
> > I fixed it up (see below) and can carry the fix as necessary.
> > -- 
> > Cheers,
> > Stephen Rothwell                    sfr@canb.auug.org.au
> > http://www.canb.auug.org.au/~sfr/
> > 
> > diff --cc mm/slob.c
> > index 4d1c0fc,30b870f..0000000
> > --- a/mm/slob.c
> > +++ b/mm/slob.c
> > @@@ -489,12 -482,9 +490,13 @@@ void *__kmalloc_node(size_t size, gfp_
> >   			page = virt_to_page(ret);
> >   			page->private = size;
> >   		}
> >  +
> >  +		kmemtrace_mark_alloc_node(KMEMTRACE_TYPE_KMALLOC,
> >  +					  _RET_IP_, ret,
> >  +					  size, PAGE_SIZE << order, gfp, node);
> >   	}
> >   
> > + 	kmemleak_alloc(ret, size, 1, gfp);
> >   	return ret;
> >   }
> >   EXPORT_SYMBOL(__kmalloc_node);
> 
> Hi,
> 
> Perhaps kmemleak could attach to the kmemtrace traces. I'm currently 
> working on moving kmemtrace w/ ftrace to tracepoints instead of markers, 
> it'll hit the list soon. We'll use generic names for tracepoints, like 
> trace_kmalloc_node(). If this sounds okay, tell me and I'll relocate the 
> tracepoints definitions to a slab heades. All you'll need to do is 
> attach to probes using register_trace_*(), same as kmemtrace does.

yes, that sounds worthwile to do.

	Ingo

Re: linux-next: manual merge of the kmemleak tree

[Catalin Marinas]

Eduard,

On Thu, 2009-01-15 at 12:29 +0200, Eduard - Gabriel Munteanu wrote:
> On Thu, Jan 15, 2009 at 04:27:17PM +1100, Stephen Rothwell wrote:
> > Hi Catalin,
> > 
> > Today's linux-next merge of the kmemleak tree got a conflict in mm/slob.c
> > between commit 3eae2cb24a96509e0a38cc48dc1538a2826f4e33 ("kmemtrace: SLOB
> > hooks") from the ftrace tree and commit
> > 19f8f253a808d317d34ccbbad3b15a1a8d2ac444 ("kmemleak: Add the slob memory
> > allocation/freeing hooks") from the kmemleak tree.
> > 
> > I fixed it up (see below) and can carry the fix as necessary.
> > -- 
> > Cheers,
> > Stephen Rothwell                    sfr@canb.auug.org.au
> > http://www.canb.auug.org.au/~sfr/
> > 
> > diff --cc mm/slob.c
> > index 4d1c0fc,30b870f..0000000
> > --- a/mm/slob.c
> > +++ b/mm/slob.c
> > @@@ -489,12 -482,9 +490,13 @@@ void *__kmalloc_node(size_t size, gfp_
> >   			page = virt_to_page(ret);
> >   			page->private = size;
> >   		}
> >  +
> >  +		kmemtrace_mark_alloc_node(KMEMTRACE_TYPE_KMALLOC,
> >  +					  _RET_IP_, ret,
> >  +					  size, PAGE_SIZE << order, gfp, node);
> >   	}
> >   
> > + 	kmemleak_alloc(ret, size, 1, gfp);
> >   	return ret;
> >   }
> >   EXPORT_SYMBOL(__kmalloc_node);
> 
> Hi,
> 
> Perhaps kmemleak could attach to the kmemtrace traces. I'm currently
> working on moving kmemtrace w/ ftrace to tracepoints instead of markers,
> it'll hit the list soon. We'll use generic names for tracepoints, like
> trace_kmalloc_node(). If this sounds okay, tell me and I'll relocate the
> tracepoints definitions to a slab heades. All you'll need to do is
> attach to probes using register_trace_*(), same as kmemtrace does.

It sounds OK. There may be some other places where kmemleak callbacks
are needed (vmalloc, module.c) but I can add those directly.

The only issue is that kmemleak would need to register the callbacks
before the slab allocator is initialised (otherwise it may miss some
allocations). So it would need a 3-stage initialisation - pre-slab,
post-slab and late_initcall.

-- 
Catalin

Re: linux-next: manual merge of the kmemleak tree

[Ingo Molnar]

* Catalin Marinas <catalin.marinas@arm.com> wrote:

> Eduard,
> 
> On Thu, 2009-01-15 at 12:29 +0200, Eduard - Gabriel Munteanu wrote:
> > On Thu, Jan 15, 2009 at 04:27:17PM +1100, Stephen Rothwell wrote:
> > > Hi Catalin,
> > > 
> > > Today's linux-next merge of the kmemleak tree got a conflict in mm/slob.c
> > > between commit 3eae2cb24a96509e0a38cc48dc1538a2826f4e33 ("kmemtrace: SLOB
> > > hooks") from the ftrace tree and commit
> > > 19f8f253a808d317d34ccbbad3b15a1a8d2ac444 ("kmemleak: Add the slob memory
> > > allocation/freeing hooks") from the kmemleak tree.
> > > 
> > > I fixed it up (see below) and can carry the fix as necessary.
> > > -- 
> > > Cheers,
> > > Stephen Rothwell                    sfr@canb.auug.org.au
> > > http://www.canb.auug.org.au/~sfr/
> > > 
> > > diff --cc mm/slob.c
> > > index 4d1c0fc,30b870f..0000000
> > > --- a/mm/slob.c
> > > +++ b/mm/slob.c
> > > @@@ -489,12 -482,9 +490,13 @@@ void *__kmalloc_node(size_t size, gfp_
> > >   			page = virt_to_page(ret);
> > >   			page->private = size;
> > >   		}
> > >  +
> > >  +		kmemtrace_mark_alloc_node(KMEMTRACE_TYPE_KMALLOC,
> > >  +					  _RET_IP_, ret,
> > >  +					  size, PAGE_SIZE << order, gfp, node);
> > >   	}
> > >   
> > > + 	kmemleak_alloc(ret, size, 1, gfp);
> > >   	return ret;
> > >   }
> > >   EXPORT_SYMBOL(__kmalloc_node);
> > 
> > Hi,
> > 
> > Perhaps kmemleak could attach to the kmemtrace traces. I'm currently
> > working on moving kmemtrace w/ ftrace to tracepoints instead of markers,
> > it'll hit the list soon. We'll use generic names for tracepoints, like
> > trace_kmalloc_node(). If this sounds okay, tell me and I'll relocate the
> > tracepoints definitions to a slab heades. All you'll need to do is
> > attach to probes using register_trace_*(), same as kmemtrace does.
> 
> It sounds OK. There may be some other places where kmemleak callbacks 
> are needed (vmalloc, module.c) but I can add those directly.

i'd suggest to add tracepoints there too, and link them up to kmemtrace as 
well. They do belong in the broad category of 'kernel memory allocators', 
and it's more consistent (and less intrusive) this way.

	Ingo

Re: linux-next: manual merge of the kmemleak tree

[Eduard - Gabriel Munteanu]

On Thu, Jan 15, 2009 at 12:04:57PM +0000, Catalin Marinas wrote:
> The only issue is that kmemleak would need to register the callbacks
> before the slab allocator is initialised (otherwise it may miss some
> allocations). So it would need a 3-stage initialisation - pre-slab,
> post-slab and late_initcall.

Sure, that is not a problem, as kmemtrace needn't be compiled in for
the tracepoints to work. As long as they're defined in some header and
included, you can register multiple probes from all over the kernel.
This also means you won't have to interact with kmemtrace code.


	Eduard

linux-next: manual merge of the kmemleak tree

[Stephen Rothwell]

Hi Catalin,

Today's linux-next merge of the kmemleak tree got a conflict in
mm/vmalloc.c between commit 822c18f2e38cbc775792ab65ace4f9198678dec9
("alpha: fix vmalloc breakage") from Linus' tree and commit
2465f1b33e3031313375b2992498560ad3ae5780 ("kmemleak: Add the vmalloc
memory allocation/freeing hooks") from the kmemleak tree.

Just overlapping additions.  I fixed it up (see below) and can carry the
fix as necessary (but it could be fixed by merging Linus' tree into the
kmemleak tree).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --cc mm/vmalloc.c
index 75f49d3,98af10c..0000000
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@@ -23,7 -24,7 +23,8 @@@
  #include <linux/rbtree.h>
  #include <linux/radix-tree.h>
  #include <linux/rcupdate.h>
 +#include <linux/bootmem.h>
+ #include <linux/kmemleak.h>
  
  #include <asm/atomic.h>
  #include <asm/uaccess.h>

Re: linux-next: manual merge of the kmemleak tree

[Catalin Marinas]

On Thu, 2009-01-15 at 19:49 +0200, Eduard - Gabriel Munteanu wrote:
> On Thu, Jan 15, 2009 at 12:04:57PM +0000, Catalin Marinas wrote:
> > The only issue is that kmemleak would need to register the callbacks
> > before the slab allocator is initialised (otherwise it may miss some
> > allocations). So it would need a 3-stage initialisation - pre-slab,
> > post-slab and late_initcall.
> 
> Sure, that is not a problem, as kmemtrace needn't be compiled in for
> the tracepoints to work. As long as they're defined in some header and
> included, you can register multiple probes from all over the kernel.
> This also means you won't have to interact with kmemtrace code.

I noticed that the memory allocation tracepoints were merged into
mainline. I'll modify kmemleak to use them and probably add another for
vmalloc.

Since tracing is available even without KMEMTRACE, does it make sense to
have kmem_cache_alloc_notrace depend on CONFIG_TRACEPOINTS (or something
else)?

Thanks.

-- 
Catalin

Re: linux-next: manual merge of the kmemleak tree

[Catalin Marinas]

On Tue, 2009-04-21 at 12:14 +0100, Catalin Marinas wrote:
> On Thu, 2009-01-15 at 19:49 +0200, Eduard - Gabriel Munteanu wrote:
> > On Thu, Jan 15, 2009 at 12:04:57PM +0000, Catalin Marinas wrote:
> > > The only issue is that kmemleak would need to register the callbacks
> > > before the slab allocator is initialised (otherwise it may miss some
> > > allocations). So it would need a 3-stage initialisation - pre-slab,
> > > post-slab and late_initcall.
> > 
> > Sure, that is not a problem, as kmemtrace needn't be compiled in for
> > the tracepoints to work. As long as they're defined in some header and
> > included, you can register multiple probes from all over the kernel.
> > This also means you won't have to interact with kmemtrace code.
> 
> I noticed that the memory allocation tracepoints were merged into
> mainline. I'll modify kmemleak to use them and probably add another for
> vmalloc.

After a quick look, it turns out not to be so simple. Kmemleak needs to
trace all the memory allocations (missing some could cause false
positives) and it currently has a static buffer to store the first
allocations before kmemleak is fully initialised.

Registering a probe requires memory allocations and therefore it needs
to be done after kmem_cache_init(). It means that kmemleak would miss
several allocations before it can register the probes. I don't see any
solution other than inserting kmemleak_*() calls near the tracing hooks.

Any other suggestion? Thanks.

-- 
Catalin

Re: linux-next: manual merge of the kmemleak tree

[Pekka Enberg]

Hi Catalin,

Catalin Marinas wrote:
>> I noticed that the memory allocation tracepoints were merged into
>> mainline. I'll modify kmemleak to use them and probably add another for
>> vmalloc.
> 
> After a quick look, it turns out not to be so simple. Kmemleak needs to
> trace all the memory allocations (missing some could cause false
> positives) and it currently has a static buffer to store the first
> allocations before kmemleak is fully initialised.
> 
> Registering a probe requires memory allocations and therefore it needs
> to be done after kmem_cache_init(). It means that kmemleak would miss
> several allocations before it can register the probes. I don't see any
> solution other than inserting kmemleak_*() calls near the tracing hooks.
> 
> Any other suggestion? Thanks.

Yup, sounds like kmemleak hooks should stay there as-is.

			Pekka