[PATCH] cgroup/kmemcheck: No need to annotate base anymore

[PATCH] cgroup/kmemcheck: No need to annotate base anymore

[Steven Rostedt]

When the cgroup base was allocated with kmalloc, it was necessary to
annotate the variable with kmemcheck_not_leak(). But because it has
recently been changed to be allocated with alloc_page(), the annotation
is no longer needed.

I was triggering this output:

allocated 8388608 bytes of page_cgroup
please try 'cgroup_disable=memory' option if you don't want memory cgroups
kmemleak: Trying to color unknown object at 0xf5840000 as Grey
Pid: 0, comm: swapper Not tainted 3.0.0-test #12
Call Trace:
 [<c17e34e6>] ? printk+0x1d/0x1f^M
 [<c10e2941>] paint_ptr+0x4f/0x78
 [<c178ab57>] kmemleak_not_leak+0x58/0x7d
 [<c108ae9f>] ? __rcu_read_unlock+0x9/0x7d
 [<c1cdb462>] kmemleak_init+0x19d/0x1e9
 [<c1cbf771>] start_kernel+0x346/0x3ec
 [<c1cbf1b4>] ? loglevel+0x18/0x18
 [<c1cbf0aa>] i386_start_kernel+0xaa/0xb0

After a bit of debugging I tracked the object 0xf840000 (and others)
down to the cgroup code. The change from allocating base with kmalloc to
alloc_page() has the base not calling kmemleak_alloc() which adds the
pointer to the object_tree_root, but kmemleak_not_leak() adds it to the
crt_early_log[] table. On kmemleak_init(), the entry is found in the
early_log[] but not the object_tree_root, and this error message is
displayed.

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

diff --git a/mm/page_cgroup.c b/mm/page_cgroup.c
index 53bffc6..955a49f 100644
--- a/mm/page_cgroup.c
+++ b/mm/page_cgroup.c
@@ -9,7 +9,6 @@
 #include <linux/vmalloc.h>
 #include <linux/cgroup.h>
 #include <linux/swapops.h>
-#include <linux/kmemleak.h>
 
 static void __meminit init_page_cgroup(struct page_cgroup *pc, unsigned long id)
 {
@@ -179,13 +178,6 @@ static int __meminit init_section_page_cgroup(unsigned long pfn, int nid)
 	table_size = sizeof(struct page_cgroup) * PAGES_PER_SECTION;
 	base = alloc_page_cgroup(table_size, nid);
 
-	/*
-	 * The value stored in section->page_cgroup is (base - pfn)
-	 * and it does not point to the memory block allocated above,
-	 * causing kmemleak false positives.
-	 */
-	kmemleak_not_leak(base);
-
 	if (!base) {
 		printk(KERN_ERR "page cgroup allocation failure\n");
 		return -ENOMEM;

Re: [PATCH] cgroup/kmemcheck: No need to annotate base anymore

[Michal Hocko]

On Tue 26-07-11 13:05:11, Steven Rostedt wrote:
> When the cgroup base was allocated with kmalloc, it was necessary to
> annotate the variable with kmemcheck_not_leak(). But because it has
> recently been changed to be allocated with alloc_page(), the annotation
> is no longer needed.
> 
> I was triggering this output:
> 
> allocated 8388608 bytes of page_cgroup
> please try 'cgroup_disable=memory' option if you don't want memory cgroups
> kmemleak: Trying to color unknown object at 0xf5840000 as Grey
> Pid: 0, comm: swapper Not tainted 3.0.0-test #12
> Call Trace:
>  [<c17e34e6>] ? printk+0x1d/0x1f^M
>  [<c10e2941>] paint_ptr+0x4f/0x78
>  [<c178ab57>] kmemleak_not_leak+0x58/0x7d
>  [<c108ae9f>] ? __rcu_read_unlock+0x9/0x7d
>  [<c1cdb462>] kmemleak_init+0x19d/0x1e9
>  [<c1cbf771>] start_kernel+0x346/0x3ec
>  [<c1cbf1b4>] ? loglevel+0x18/0x18
>  [<c1cbf0aa>] i386_start_kernel+0xaa/0xb0
> 
> After a bit of debugging I tracked the object 0xf840000 (and others)
> down to the cgroup code. The change from allocating base with kmalloc to
> alloc_page() has the base not calling kmemleak_alloc() which adds the
> pointer to the object_tree_root, but kmemleak_not_leak() adds it to the
> crt_early_log[] table. On kmemleak_init(), the entry is found in the
> early_log[] but not the object_tree_root, and this error message is
> displayed.

We can still fall back to vmalloc allocation (even though it is really
not probable that alloc_pages_exact_nid would fail that early).
Is vmalloc a problem here? (sorry I am not familiar with kmemleak
internals) The original code didn't distinguish kmalloc vs. vmalloc.

> 
> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
> 
> diff --git a/mm/page_cgroup.c b/mm/page_cgroup.c
> index 53bffc6..955a49f 100644
> --- a/mm/page_cgroup.c
> +++ b/mm/page_cgroup.c
> @@ -9,7 +9,6 @@
>  #include <linux/vmalloc.h>
>  #include <linux/cgroup.h>
>  #include <linux/swapops.h>
> -#include <linux/kmemleak.h>
>  
>  static void __meminit init_page_cgroup(struct page_cgroup *pc, unsigned long id)
>  {
> @@ -179,13 +178,6 @@ static int __meminit init_section_page_cgroup(unsigned long pfn, int nid)
>  	table_size = sizeof(struct page_cgroup) * PAGES_PER_SECTION;
>  	base = alloc_page_cgroup(table_size, nid);
>  
> -	/*
> -	 * The value stored in section->page_cgroup is (base - pfn)
> -	 * and it does not point to the memory block allocated above,
> -	 * causing kmemleak false positives.
> -	 */
> -	kmemleak_not_leak(base);
> -
>  	if (!base) {
>  		printk(KERN_ERR "page cgroup allocation failure\n");
>  		return -ENOMEM;
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9    
Czech Republic

Re: [PATCH] cgroup/kmemcheck: No need to annotate base anymore

[Steven Rostedt]

On Tue, 2011-07-26 at 19:38 +0200, Michal Hocko wrote:
> On Tue 26-07-11 13:05:11, Steven Rostedt wrote:
> > When the cgroup base was allocated with kmalloc, it was necessary to
> > annotate the variable with kmemcheck_not_leak(). But because it has
> > recently been changed to be allocated with alloc_page(), the annotation
> > is no longer needed.
> > 
> > I was triggering this output:
> > 
> > allocated 8388608 bytes of page_cgroup
> > please try 'cgroup_disable=memory' option if you don't want memory cgroups
> > kmemleak: Trying to color unknown object at 0xf5840000 as Grey
> > Pid: 0, comm: swapper Not tainted 3.0.0-test #12
> > Call Trace:
> >  [<c17e34e6>] ? printk+0x1d/0x1f^M
> >  [<c10e2941>] paint_ptr+0x4f/0x78
> >  [<c178ab57>] kmemleak_not_leak+0x58/0x7d
> >  [<c108ae9f>] ? __rcu_read_unlock+0x9/0x7d
> >  [<c1cdb462>] kmemleak_init+0x19d/0x1e9
> >  [<c1cbf771>] start_kernel+0x346/0x3ec
> >  [<c1cbf1b4>] ? loglevel+0x18/0x18
> >  [<c1cbf0aa>] i386_start_kernel+0xaa/0xb0
> > 
> > After a bit of debugging I tracked the object 0xf840000 (and others)
> > down to the cgroup code. The change from allocating base with kmalloc to
> > alloc_page() has the base not calling kmemleak_alloc() which adds the
> > pointer to the object_tree_root, but kmemleak_not_leak() adds it to the
> > crt_early_log[] table. On kmemleak_init(), the entry is found in the
> > early_log[] but not the object_tree_root, and this error message is
> > displayed.
> 
> We can still fall back to vmalloc allocation (even though it is really
> not probable that alloc_pages_exact_nid would fail that early).
> Is vmalloc a problem here? (sorry I am not familiar with kmemleak
> internals) The original code didn't distinguish kmalloc vs. vmalloc.
> 

Good question. I forgot to add the maintainer of kmemleak to the Cc
list. (fixed here).

-- Steve

> > 
> > Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
> > 
> > diff --git a/mm/page_cgroup.c b/mm/page_cgroup.c
> > index 53bffc6..955a49f 100644
> > --- a/mm/page_cgroup.c
> > +++ b/mm/page_cgroup.c
> > @@ -9,7 +9,6 @@
> >  #include <linux/vmalloc.h>
> >  #include <linux/cgroup.h>
> >  #include <linux/swapops.h>
> > -#include <linux/kmemleak.h>
> >  
> >  static void __meminit init_page_cgroup(struct page_cgroup *pc, unsigned long id)
> >  {
> > @@ -179,13 +178,6 @@ static int __meminit init_section_page_cgroup(unsigned long pfn, int nid)
> >  	table_size = sizeof(struct page_cgroup) * PAGES_PER_SECTION;
> >  	base = alloc_page_cgroup(table_size, nid);
> >  
> > -	/*
> > -	 * The value stored in section->page_cgroup is (base - pfn)
> > -	 * and it does not point to the memory block allocated above,
> > -	 * causing kmemleak false positives.
> > -	 */
> > -	kmemleak_not_leak(base);
> > -
> >  	if (!base) {
> >  		printk(KERN_ERR "page cgroup allocation failure\n");
> >  		return -ENOMEM;
> > 
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: [PATCH] cgroup/kmemcheck: No need to annotate base anymore

[Steven Rostedt]

On Tue, 2011-07-26 at 13:41 -0400, Steven Rostedt wrote:

> > We can still fall back to vmalloc allocation (even though it is really
> > not probable that alloc_pages_exact_nid would fail that early).
> > Is vmalloc a problem here? (sorry I am not familiar with kmemleak
> > internals) The original code didn't distinguish kmalloc vs. vmalloc.
> > 
> 
> Good question. I forgot to add the maintainer of kmemleak to the Cc
> list. (fixed here).

Depending on the answer, I suspect that the result will be to keep the
not_leak call, and just add a call directly to kmemleak_alloc() in the
page_alloc() side.

I'll have a patch ready on hand when we find out :)

-- Steve

[PATCH v2] cgroup/kmemcheck: Annotate alloc_page() for cgroup allocations

[Steven Rostedt]

When the cgroup base was allocated with kmalloc, it was necessary to
annotate the variable with kmemcheck_not_leak(). But because it has
recently been changed to be allocated with alloc_page() (which skips
kmemleak checks) causes a warning on boot up.

I was triggering this output:

allocated 8388608 bytes of page_cgroup
please try 'cgroup_disable=memory' option if you don't want memory
cgroups
kmemleak: Trying to color unknown object at 0xf5840000 as Grey
Pid: 0, comm: swapper Not tainted 3.0.0-test #12
Call Trace:
 [<c17e34e6>] ? printk+0x1d/0x1f^M
 [<c10e2941>] paint_ptr+0x4f/0x78
 [<c178ab57>] kmemleak_not_leak+0x58/0x7d
 [<c108ae9f>] ? __rcu_read_unlock+0x9/0x7d
 [<c1cdb462>] kmemleak_init+0x19d/0x1e9
 [<c1cbf771>] start_kernel+0x346/0x3ec
 [<c1cbf1b4>] ? loglevel+0x18/0x18
 [<c1cbf0aa>] i386_start_kernel+0xaa/0xb0

After a bit of debugging I tracked the object 0xf840000 (and others)
down to the cgroup code. The change from allocating base with kmalloc to
alloc_page() has the base not calling kmemleak_alloc() which adds the
pointer to the object_tree_root, but kmemleak_not_leak() adds it to the
crt_early_log[] table. On kmemleak_init(), the entry is found in the
early_log[] but not the object_tree_root, and this error message is
displayed.

If alloc_page() fails then it defaults back to vmalloc() which still
uses the kmemleak_alloc() which makes us still need the
kmemleak_not_leak() call. The solution is to call the kmemleak_alloc()
directly if the alloc_page() succeeds.

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

diff --git a/mm/page_cgroup.c b/mm/page_cgroup.c
index 53bffc6..79c0e00 100644
--- a/mm/page_cgroup.c
+++ b/mm/page_cgroup.c
@@ -135,8 +135,10 @@ static void *__meminit alloc_page_cgroup(size_t size, int nid)
 	void *addr = NULL;
 
 	addr = alloc_pages_exact_nid(nid, size, GFP_KERNEL | __GFP_NOWARN);
-	if (addr)
+	if (addr) {
+		kmemleak_alloc(addr, size, 1, GFP_KERNEL | __GFP_NOWARN);
 		return addr;
+	}
 
 	if (node_state(nid, N_HIGH_MEMORY))
 		addr = vmalloc_node(size, nid);

Re: [PATCH v2] cgroup/kmemcheck: Annotate alloc_page() for cgroup allocations

[Michal Hocko]

On Tue 26-07-11 14:17:29, Steven Rostedt wrote:
> When the cgroup base was allocated with kmalloc, it was necessary to
> annotate the variable with kmemcheck_not_leak(). But because it has
> recently been changed to be allocated with alloc_page() (which skips
> kmemleak checks) causes a warning on boot up.
> 
> I was triggering this output:
> 
> allocated 8388608 bytes of page_cgroup
> please try 'cgroup_disable=memory' option if you don't want memory
> cgroups
> kmemleak: Trying to color unknown object at 0xf5840000 as Grey
> Pid: 0, comm: swapper Not tainted 3.0.0-test #12
> Call Trace:
>  [<c17e34e6>] ? printk+0x1d/0x1f^M
>  [<c10e2941>] paint_ptr+0x4f/0x78
>  [<c178ab57>] kmemleak_not_leak+0x58/0x7d
>  [<c108ae9f>] ? __rcu_read_unlock+0x9/0x7d
>  [<c1cdb462>] kmemleak_init+0x19d/0x1e9
>  [<c1cbf771>] start_kernel+0x346/0x3ec
>  [<c1cbf1b4>] ? loglevel+0x18/0x18
>  [<c1cbf0aa>] i386_start_kernel+0xaa/0xb0
> 
> After a bit of debugging I tracked the object 0xf840000 (and others)
> down to the cgroup code. The change from allocating base with kmalloc to
> alloc_page() has the base not calling kmemleak_alloc() which adds the
> pointer to the object_tree_root, but kmemleak_not_leak() adds it to the
> crt_early_log[] table. On kmemleak_init(), the entry is found in the
> early_log[] but not the object_tree_root, and this error message is
> displayed.
> 
> If alloc_page() fails then it defaults back to vmalloc() which still
> uses the kmemleak_alloc() which makes us still need the
> kmemleak_not_leak() call. The solution is to call the kmemleak_alloc()
> directly if the alloc_page() succeeds.

OK, so you are making the allocation [kv]malloc like wrt. kmemleak.
I can see that kmalloc_order does the exactly same thing and there are
couple of oders that do it as well so I guess this should be correct.

> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

Maybe just a nit. What about making 
gfp_t flags = GFP_KERNEL | __GFP_NOWARN;
and use it at both places?

Anyway feel free to add my:
Reviewed-by: Michal Hocko <mhocko@suse.cz>

> 
> diff --git a/mm/page_cgroup.c b/mm/page_cgroup.c
> index 53bffc6..79c0e00 100644
> --- a/mm/page_cgroup.c
> +++ b/mm/page_cgroup.c
> @@ -135,8 +135,10 @@ static void *__meminit alloc_page_cgroup(size_t size, int nid)
>  	void *addr = NULL;
>  
>  	addr = alloc_pages_exact_nid(nid, size, GFP_KERNEL | __GFP_NOWARN);
> -	if (addr)
> +	if (addr) {
> +		kmemleak_alloc(addr, size, 1, GFP_KERNEL | __GFP_NOWARN);
>  		return addr;
> +	}
>  
>  	if (node_state(nid, N_HIGH_MEMORY))
>  		addr = vmalloc_node(size, nid);
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9    
Czech Republic

Re: [PATCH v2] cgroup/kmemcheck: Annotate alloc_page() for cgroup allocations

[Steven Rostedt]

On Tue, 2011-07-26 at 20:43 +0200, Michal Hocko wrote:

> Maybe just a nit. What about making 
> gfp_t flags = GFP_KERNEL | __GFP_NOWARN;
> and use it at both places?

I actually thought about that, but was too lazy to do it ;)


> 
> Anyway feel free to add my:
> Reviewed-by: Michal Hocko <mhocko@suse.cz>
> 

Thanks, I'll send out a v3 with the updates.

-- Steve

[PATCH v3] cgroup/kmemcheck: Annotate alloc_page() for cgroup allocations

[Steven Rostedt]

When the cgroup base was allocated with kmalloc, it was necessary to
annotate the variable with kmemcheck_not_leak(). But because it has
recently been changed to be allocated with alloc_page() (which skips
kmemleak checks) causes a warning on boot up.

I was triggering this output:

allocated 8388608 bytes of page_cgroup
please try 'cgroup_disable=memory' option if you don't want memory cgroups
kmemleak: Trying to color unknown object at 0xf5840000 as Grey
Pid: 0, comm: swapper Not tainted 3.0.0-test #12
Call Trace:
 [<c17e34e6>] ? printk+0x1d/0x1f^M
 [<c10e2941>] paint_ptr+0x4f/0x78
 [<c178ab57>] kmemleak_not_leak+0x58/0x7d
 [<c108ae9f>] ? __rcu_read_unlock+0x9/0x7d
 [<c1cdb462>] kmemleak_init+0x19d/0x1e9
 [<c1cbf771>] start_kernel+0x346/0x3ec
 [<c1cbf1b4>] ? loglevel+0x18/0x18
 [<c1cbf0aa>] i386_start_kernel+0xaa/0xb0

After a bit of debugging I tracked the object 0xf840000 (and others)
down to the cgroup code. The change from allocating base with kmalloc to
alloc_page() has the base not calling kmemleak_alloc() which adds the
pointer to the object_tree_root, but kmemleak_not_leak() adds it to the
crt_early_log[] table. On kmemleak_init(), the entry is found in the
early_log[] but not the object_tree_root, and this error message is
displayed.

If alloc_page() fails then it defaults back to vmalloc() which still
uses the kmemleak_alloc() which makes us still need the
kmemleak_not_leak() call. The solution is to call the kmemleak_alloc()
directly if the alloc_page() succeeds.

Reviewed-by: Michal Hocko <mhocko@suse.cz>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

diff --git a/mm/page_cgroup.c b/mm/page_cgroup.c
index 53bffc6..1eb534a 100644
--- a/mm/page_cgroup.c
+++ b/mm/page_cgroup.c
@@ -133,10 +133,13 @@ struct page *lookup_cgroup_page(struct page_cgroup *pc)
 static void *__meminit alloc_page_cgroup(size_t size, int nid)
 {
 	void *addr = NULL;
+	gfp_t flags = GFP_KERNEL | __GFP_NOWARN;
 
-	addr = alloc_pages_exact_nid(nid, size, GFP_KERNEL | __GFP_NOWARN);
-	if (addr)
+	addr = alloc_pages_exact_nid(nid, size, flags);
+	if (addr) {
+		kmemleak_alloc(addr, size, 1, flags);
 		return addr;
+	}
 
 	if (node_state(nid, N_HIGH_MEMORY))
 		addr = vmalloc_node(size, nid);

Re: [PATCH v3] cgroup/kmemcheck: Annotate alloc_page() for cgroup allocations

[Johannes Weiner]

On Tue, Jul 26, 2011 at 03:19:16PM -0400, Steven Rostedt wrote:
> When the cgroup base was allocated with kmalloc, it was necessary to
> annotate the variable with kmemcheck_not_leak(). But because it has
> recently been changed to be allocated with alloc_page() (which skips
> kmemleak checks) causes a warning on boot up.
> 
> I was triggering this output:
> 
> allocated 8388608 bytes of page_cgroup
> please try 'cgroup_disable=memory' option if you don't want memory cgroups
> kmemleak: Trying to color unknown object at 0xf5840000 as Grey
> Pid: 0, comm: swapper Not tainted 3.0.0-test #12
> Call Trace:
>  [<c17e34e6>] ? printk+0x1d/0x1f^M
>  [<c10e2941>] paint_ptr+0x4f/0x78
>  [<c178ab57>] kmemleak_not_leak+0x58/0x7d
>  [<c108ae9f>] ? __rcu_read_unlock+0x9/0x7d
>  [<c1cdb462>] kmemleak_init+0x19d/0x1e9
>  [<c1cbf771>] start_kernel+0x346/0x3ec
>  [<c1cbf1b4>] ? loglevel+0x18/0x18
>  [<c1cbf0aa>] i386_start_kernel+0xaa/0xb0
> 
> After a bit of debugging I tracked the object 0xf840000 (and others)
> down to the cgroup code. The change from allocating base with kmalloc to
> alloc_page() has the base not calling kmemleak_alloc() which adds the
> pointer to the object_tree_root, but kmemleak_not_leak() adds it to the
> crt_early_log[] table. On kmemleak_init(), the entry is found in the
> early_log[] but not the object_tree_root, and this error message is
> displayed.
> 
> If alloc_page() fails then it defaults back to vmalloc() which still
> uses the kmemleak_alloc() which makes us still need the
> kmemleak_not_leak() call. The solution is to call the kmemleak_alloc()
> directly if the alloc_page() succeeds.
> 
> Reviewed-by: Michal Hocko <mhocko@suse.cz>
> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

Acked-by: Johannes Weiner <hannes@cmpxchg.org>

Re: [PATCH v3] cgroup/kmemcheck: Annotate alloc_page() for cgroup allocations

[Minchan Kim]

On Wed, Jul 27, 2011 at 4:19 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
> When the cgroup base was allocated with kmalloc, it was necessary to
> annotate the variable with kmemcheck_not_leak(). But because it has
> recently been changed to be allocated with alloc_page() (which skips
> kmemleak checks) causes a warning on boot up.
>
> I was triggering this output:
>
> allocated 8388608 bytes of page_cgroup
> please try 'cgroup_disable=memory' option if you don't want memory cgroups
> kmemleak: Trying to color unknown object at 0xf5840000 as Grey
> Pid: 0, comm: swapper Not tainted 3.0.0-test #12
> Call Trace:
>  [<c17e34e6>] ? printk+0x1d/0x1f^M
>  [<c10e2941>] paint_ptr+0x4f/0x78
>  [<c178ab57>] kmemleak_not_leak+0x58/0x7d
>  [<c108ae9f>] ? __rcu_read_unlock+0x9/0x7d
>  [<c1cdb462>] kmemleak_init+0x19d/0x1e9
>  [<c1cbf771>] start_kernel+0x346/0x3ec
>  [<c1cbf1b4>] ? loglevel+0x18/0x18
>  [<c1cbf0aa>] i386_start_kernel+0xaa/0xb0
>
> After a bit of debugging I tracked the object 0xf840000 (and others)
> down to the cgroup code. The change from allocating base with kmalloc to
> alloc_page() has the base not calling kmemleak_alloc() which adds the
> pointer to the object_tree_root, but kmemleak_not_leak() adds it to the
> crt_early_log[] table. On kmemleak_init(), the entry is found in the
> early_log[] but not the object_tree_root, and this error message is
> displayed.
>
> If alloc_page() fails then it defaults back to vmalloc() which still
> uses the kmemleak_alloc() which makes us still need the
> kmemleak_not_leak() call. The solution is to call the kmemleak_alloc()
> directly if the alloc_page() succeeds.
>
> Reviewed-by: Michal Hocko <mhocko@suse.cz>
> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Reviewed-by: Minchan Kim <minchan.kim@gmail.com>

-- 
Kind regards,
Minchan Kim

Re: [PATCH v3] cgroup/kmemcheck: Annotate alloc_page() for cgroup allocations

[KAMEZAWA Hiroyuki]

On Tue, 26 Jul 2011 15:19:16 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> When the cgroup base was allocated with kmalloc, it was necessary to
> annotate the variable with kmemcheck_not_leak(). But because it has
> recently been changed to be allocated with alloc_page() (which skips
> kmemleak checks) causes a warning on boot up.
> 
> I was triggering this output:
> 
> allocated 8388608 bytes of page_cgroup
> please try 'cgroup_disable=memory' option if you don't want memory cgroups
> kmemleak: Trying to color unknown object at 0xf5840000 as Grey
> Pid: 0, comm: swapper Not tainted 3.0.0-test #12
> Call Trace:
>  [<c17e34e6>] ? printk+0x1d/0x1f^M
>  [<c10e2941>] paint_ptr+0x4f/0x78
>  [<c178ab57>] kmemleak_not_leak+0x58/0x7d
>  [<c108ae9f>] ? __rcu_read_unlock+0x9/0x7d
>  [<c1cdb462>] kmemleak_init+0x19d/0x1e9
>  [<c1cbf771>] start_kernel+0x346/0x3ec
>  [<c1cbf1b4>] ? loglevel+0x18/0x18
>  [<c1cbf0aa>] i386_start_kernel+0xaa/0xb0
> 
> After a bit of debugging I tracked the object 0xf840000 (and others)
> down to the cgroup code. The change from allocating base with kmalloc to
> alloc_page() has the base not calling kmemleak_alloc() which adds the
> pointer to the object_tree_root, but kmemleak_not_leak() adds it to the
> crt_early_log[] table. On kmemleak_init(), the entry is found in the
> early_log[] but not the object_tree_root, and this error message is
> displayed.
> 
> If alloc_page() fails then it defaults back to vmalloc() which still
> uses the kmemleak_alloc() which makes us still need the
> kmemleak_not_leak() call. The solution is to call the kmemleak_alloc()
> directly if the alloc_page() succeeds.
> 
> Reviewed-by: Michal Hocko <mhocko@suse.cz>
> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
> 
Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>

[PATCH v3 RESEND] cgroup/kmemcheck: Annotate alloc_page() for cgroup allocations

[Steven Rostedt]

[ Resending with CGROUP maintainers Cc'd this time ]

When the cgroup base was allocated with kmalloc, it was necessary to
annotate the variable with kmemcheck_not_leak(). But because it has
recently been changed to be allocated with alloc_page() (which skips
kmemleak checks) causes a warning on boot up.

I was triggering this output:

allocated 8388608 bytes of page_cgroup
please try 'cgroup_disable=memory' option if you don't want memory cgroups
kmemleak: Trying to color unknown object at 0xf5840000 as Grey
Pid: 0, comm: swapper Not tainted 3.0.0-test #12
Call Trace:
 [<c17e34e6>] ? printk+0x1d/0x1f^M
 [<c10e2941>] paint_ptr+0x4f/0x78
 [<c178ab57>] kmemleak_not_leak+0x58/0x7d
 [<c108ae9f>] ? __rcu_read_unlock+0x9/0x7d
 [<c1cdb462>] kmemleak_init+0x19d/0x1e9
 [<c1cbf771>] start_kernel+0x346/0x3ec
 [<c1cbf1b4>] ? loglevel+0x18/0x18
 [<c1cbf0aa>] i386_start_kernel+0xaa/0xb0

After a bit of debugging I tracked the object 0xf840000 (and others)
down to the cgroup code. The change from allocating base with kmalloc to
alloc_page() has the base not calling kmemleak_alloc() which adds the
pointer to the object_tree_root, but kmemleak_not_leak() adds it to the
crt_early_log[] table. On kmemleak_init(), the entry is found in the
early_log[] but not the object_tree_root, and this error message is
displayed.

If alloc_page() fails then it defaults back to vmalloc() which still
uses the kmemleak_alloc() which makes us still need the
kmemleak_not_leak() call. The solution is to call the kmemleak_alloc()
directly if the alloc_page() succeeds.

Reviewed-by: Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org>
Reviewed-by: Minchan Kim <minchan.kim-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Acked-by: Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
Signed-off-by: Steven Rostedt <rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org>

diff --git a/mm/page_cgroup.c b/mm/page_cgroup.c
index 53bffc6..1eb534a 100644
--- a/mm/page_cgroup.c
+++ b/mm/page_cgroup.c
@@ -133,10 +133,13 @@ struct page *lookup_cgroup_page(struct page_cgroup *pc)
 static void *__meminit alloc_page_cgroup(size_t size, int nid)
 {
 	void *addr = NULL;
+	gfp_t flags = GFP_KERNEL | __GFP_NOWARN;
 
-	addr = alloc_pages_exact_nid(nid, size, GFP_KERNEL | __GFP_NOWARN);
-	if (addr)
+	addr = alloc_pages_exact_nid(nid, size, flags);
+	if (addr) {
+		kmemleak_alloc(addr, size, 1, flags);
 		return addr;
+	}
 
 	if (node_state(nid, N_HIGH_MEMORY))
 		addr = vmalloc_node(size, nid);

[PATCH v3 RESEND] cgroup/kmemcheck: Annotate alloc_page() for cgroup allocations

[Steven Rostedt]

[ Resending with CGROUP maintainers Cc'd this time ]

When the cgroup base was allocated with kmalloc, it was necessary to
annotate the variable with kmemcheck_not_leak(). But because it has
recently been changed to be allocated with alloc_page() (which skips
kmemleak checks) causes a warning on boot up.

I was triggering this output:

allocated 8388608 bytes of page_cgroup
please try 'cgroup_disable=memory' option if you don't want memory cgroups
kmemleak: Trying to color unknown object at 0xf5840000 as Grey
Pid: 0, comm: swapper Not tainted 3.0.0-test #12
Call Trace:
 [<c17e34e6>] ? printk+0x1d/0x1f^M
 [<c10e2941>] paint_ptr+0x4f/0x78
 [<c178ab57>] kmemleak_not_leak+0x58/0x7d
 [<c108ae9f>] ? __rcu_read_unlock+0x9/0x7d
 [<c1cdb462>] kmemleak_init+0x19d/0x1e9
 [<c1cbf771>] start_kernel+0x346/0x3ec
 [<c1cbf1b4>] ? loglevel+0x18/0x18
 [<c1cbf0aa>] i386_start_kernel+0xaa/0xb0

After a bit of debugging I tracked the object 0xf840000 (and others)
down to the cgroup code. The change from allocating base with kmalloc to
alloc_page() has the base not calling kmemleak_alloc() which adds the
pointer to the object_tree_root, but kmemleak_not_leak() adds it to the
crt_early_log[] table. On kmemleak_init(), the entry is found in the
early_log[] but not the object_tree_root, and this error message is
displayed.

If alloc_page() fails then it defaults back to vmalloc() which still
uses the kmemleak_alloc() which makes us still need the
kmemleak_not_leak() call. The solution is to call the kmemleak_alloc()
directly if the alloc_page() succeeds.

Reviewed-by: Michal Hocko <mhocko@suse.cz>
Reviewed-by: Minchan Kim <minchan.kim@gmail.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

diff --git a/mm/page_cgroup.c b/mm/page_cgroup.c
index 53bffc6..1eb534a 100644
--- a/mm/page_cgroup.c
+++ b/mm/page_cgroup.c
@@ -133,10 +133,13 @@ struct page *lookup_cgroup_page(struct page_cgroup *pc)
 static void *__meminit alloc_page_cgroup(size_t size, int nid)
 {
 	void *addr = NULL;
+	gfp_t flags = GFP_KERNEL | __GFP_NOWARN;
 
-	addr = alloc_pages_exact_nid(nid, size, GFP_KERNEL | __GFP_NOWARN);
-	if (addr)
+	addr = alloc_pages_exact_nid(nid, size, flags);
+	if (addr) {
+		kmemleak_alloc(addr, size, 1, flags);
 		return addr;
+	}
 
 	if (node_state(nid, N_HIGH_MEMORY))
 		addr = vmalloc_node(size, nid);

Re: [PATCH v3 RESEND] cgroup/kmemcheck: Annotate alloc_page() for cgroup allocations

[Steven Rostedt]

Andrew,

On Tue, 2011-07-26 at 22:10 -0400, Steven Rostedt wrote:
> [ Resending with CGROUP maintainers Cc'd this time ]

Paul sent me a note saying that these patches usually go through -mm,
want to take them?

Thanks,

-- Steve

> 
> When the cgroup base was allocated with kmalloc, it was necessary to
> annotate the variable with kmemcheck_not_leak(). But because it has
> recently been changed to be allocated with alloc_page() (which skips
> kmemleak checks) causes a warning on boot up.
> 
> I was triggering this output:
> 
> allocated 8388608 bytes of page_cgroup
> please try 'cgroup_disable=memory' option if you don't want memory cgroups
> kmemleak: Trying to color unknown object at 0xf5840000 as Grey
> Pid: 0, comm: swapper Not tainted 3.0.0-test #12
> Call Trace:
>  [<c17e34e6>] ? printk+0x1d/0x1f^M
>  [<c10e2941>] paint_ptr+0x4f/0x78
>  [<c178ab57>] kmemleak_not_leak+0x58/0x7d
>  [<c108ae9f>] ? __rcu_read_unlock+0x9/0x7d
>  [<c1cdb462>] kmemleak_init+0x19d/0x1e9
>  [<c1cbf771>] start_kernel+0x346/0x3ec
>  [<c1cbf1b4>] ? loglevel+0x18/0x18
>  [<c1cbf0aa>] i386_start_kernel+0xaa/0xb0
> 
> After a bit of debugging I tracked the object 0xf840000 (and others)
> down to the cgroup code. The change from allocating base with kmalloc to
> alloc_page() has the base not calling kmemleak_alloc() which adds the
> pointer to the object_tree_root, but kmemleak_not_leak() adds it to the
> crt_early_log[] table. On kmemleak_init(), the entry is found in the
> early_log[] but not the object_tree_root, and this error message is
> displayed.
> 
> If alloc_page() fails then it defaults back to vmalloc() which still
> uses the kmemleak_alloc() which makes us still need the
> kmemleak_not_leak() call. The solution is to call the kmemleak_alloc()
> directly if the alloc_page() succeeds.
> 
> Reviewed-by: Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org>
> Reviewed-by: Minchan Kim <minchan.kim-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Acked-by: Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
> Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
> Signed-off-by: Steven Rostedt <rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org>
> 
> diff --git a/mm/page_cgroup.c b/mm/page_cgroup.c
> index 53bffc6..1eb534a 100644
> --- a/mm/page_cgroup.c
> +++ b/mm/page_cgroup.c
> @@ -133,10 +133,13 @@ struct page *lookup_cgroup_page(struct page_cgroup *pc)
>  static void *__meminit alloc_page_cgroup(size_t size, int nid)
>  {
>  	void *addr = NULL;
> +	gfp_t flags = GFP_KERNEL | __GFP_NOWARN;
>  
> -	addr = alloc_pages_exact_nid(nid, size, GFP_KERNEL | __GFP_NOWARN);
> -	if (addr)
> +	addr = alloc_pages_exact_nid(nid, size, flags);
> +	if (addr) {
> +		kmemleak_alloc(addr, size, 1, flags);
>  		return addr;
> +	}
>  
>  	if (node_state(nid, N_HIGH_MEMORY))
>  		addr = vmalloc_node(size, nid);
> 
> 

Re: [PATCH v3 RESEND] cgroup/kmemcheck: Annotate alloc_page() for cgroup allocations

[Steven Rostedt]

Andrew,

On Tue, 2011-07-26 at 22:10 -0400, Steven Rostedt wrote:
> [ Resending with CGROUP maintainers Cc'd this time ]

Paul sent me a note saying that these patches usually go through -mm,
want to take them?

Thanks,

-- Steve

> 
> When the cgroup base was allocated with kmalloc, it was necessary to
> annotate the variable with kmemcheck_not_leak(). But because it has
> recently been changed to be allocated with alloc_page() (which skips
> kmemleak checks) causes a warning on boot up.
> 
> I was triggering this output:
> 
> allocated 8388608 bytes of page_cgroup
> please try 'cgroup_disable=memory' option if you don't want memory cgroups
> kmemleak: Trying to color unknown object at 0xf5840000 as Grey
> Pid: 0, comm: swapper Not tainted 3.0.0-test #12
> Call Trace:
>  [<c17e34e6>] ? printk+0x1d/0x1f^M
>  [<c10e2941>] paint_ptr+0x4f/0x78
>  [<c178ab57>] kmemleak_not_leak+0x58/0x7d
>  [<c108ae9f>] ? __rcu_read_unlock+0x9/0x7d
>  [<c1cdb462>] kmemleak_init+0x19d/0x1e9
>  [<c1cbf771>] start_kernel+0x346/0x3ec
>  [<c1cbf1b4>] ? loglevel+0x18/0x18
>  [<c1cbf0aa>] i386_start_kernel+0xaa/0xb0
> 
> After a bit of debugging I tracked the object 0xf840000 (and others)
> down to the cgroup code. The change from allocating base with kmalloc to
> alloc_page() has the base not calling kmemleak_alloc() which adds the
> pointer to the object_tree_root, but kmemleak_not_leak() adds it to the
> crt_early_log[] table. On kmemleak_init(), the entry is found in the
> early_log[] but not the object_tree_root, and this error message is
> displayed.
> 
> If alloc_page() fails then it defaults back to vmalloc() which still
> uses the kmemleak_alloc() which makes us still need the
> kmemleak_not_leak() call. The solution is to call the kmemleak_alloc()
> directly if the alloc_page() succeeds.
> 
> Reviewed-by: Michal Hocko <mhocko@suse.cz>
> Reviewed-by: Minchan Kim <minchan.kim@gmail.com>
> Acked-by: Johannes Weiner <hannes@cmpxchg.org>
> Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
> 
> diff --git a/mm/page_cgroup.c b/mm/page_cgroup.c
> index 53bffc6..1eb534a 100644
> --- a/mm/page_cgroup.c
> +++ b/mm/page_cgroup.c
> @@ -133,10 +133,13 @@ struct page *lookup_cgroup_page(struct page_cgroup *pc)
>  static void *__meminit alloc_page_cgroup(size_t size, int nid)
>  {
>  	void *addr = NULL;
> +	gfp_t flags = GFP_KERNEL | __GFP_NOWARN;
>  
> -	addr = alloc_pages_exact_nid(nid, size, GFP_KERNEL | __GFP_NOWARN);
> -	if (addr)
> +	addr = alloc_pages_exact_nid(nid, size, flags);
> +	if (addr) {
> +		kmemleak_alloc(addr, size, 1, flags);
>  		return addr;
> +	}
>  
>  	if (node_state(nid, N_HIGH_MEMORY))
>  		addr = vmalloc_node(size, nid);
> 
> 

Re: [PATCH v3] cgroup/kmemcheck: Annotate alloc_page() for cgroup allocations

[Catalin Marinas]

On Tue, Jul 26, 2011 at 08:19:16PM +0100, Steven Rostedt wrote:
> When the cgroup base was allocated with kmalloc, it was necessary to
> annotate the variable with kmemcheck_not_leak(). But because it has
> recently been changed to be allocated with alloc_page() (which skips
> kmemleak checks) causes a warning on boot up.

Sorry for the delay, too much holiday over here :)

> diff --git a/mm/page_cgroup.c b/mm/page_cgroup.c
> index 53bffc6..1eb534a 100644
> --- a/mm/page_cgroup.c
> +++ b/mm/page_cgroup.c
> @@ -133,10 +133,13 @@ struct page *lookup_cgroup_page(struct page_cgroup *pc)
>  static void *__meminit alloc_page_cgroup(size_t size, int nid)
>  {
>  	void *addr = NULL;
> +	gfp_t flags = GFP_KERNEL | __GFP_NOWARN;
>  
> -	addr = alloc_pages_exact_nid(nid, size, GFP_KERNEL | __GFP_NOWARN);
> -	if (addr)
> +	addr = alloc_pages_exact_nid(nid, size, flags);
> +	if (addr) {
> +		kmemleak_alloc(addr, size, 1, flags);
>  		return addr;
> +	}
>  
>  	if (node_state(nid, N_HIGH_MEMORY))
>  		addr = vmalloc_node(size, nid);

The __GFP_NOWARN is already added by kmemleak_alloc but there is no harm
in leaving it.

One minor thing with the subject, unless you already submitted the
patch - it's kmemleak rather than kmemcheck (different things,
confusingly).

Acked-by: Catalin Marinas <catalin.marinas@arm.com>