On Wed, 10 Jul 2013, Pekka Enberg wrote: > Yes, it indeed interacts badly with kmemleak and tracing. I reverted the > commit. Here is the fix required. kmemleak.h is weird in that it cannot be included at the top of slab.h due to its corresponding dependency on slab.h. Bad situation. kmemleak.h itself should include "slab.h"... Why not fold kmemleak.h into slab.h to avoid future surprises? Subject: slabs: kmemleak.h needs to be included after constant definitions. Kmemleak.h depends on the constant defs in slab.h. It was include before them. Move the include further down. Signed-off-by: Christoph Lameter <cl@xxxxxxxxx> Index: linux/include/linux/slab.h =================================================================== --- linux.orig/include/linux/slab.h 2013-07-10 13:43:36.186641776 -0500 +++ linux/include/linux/slab.h 2013-07-10 13:44:36.735730034 -0500 @@ -14,7 +14,6 @@ #include <linux/gfp.h> #include <linux/types.h> #include <linux/workqueue.h> -#include <linux/kmemleak.h> /* @@ -97,6 +96,7 @@ #define ZERO_OR_NULL_PTR(x) ((unsigned long)(x) <= \ (unsigned long)ZERO_SIZE_PTR) +#include <linux/kmemleak.h> struct mem_cgroup; /* -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
