Messages in this thread | | | Subject | Re: [PATCH] cgroup/kmemcheck: No need to annotate base anymore | From | Steven Rostedt <> | Date | Tue, 26 Jul 2011 13:41:50 -0400 |
| |
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/ >
| |