LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* linux-next: build failure after merge of the slab tree
@ 2011-01-31  3:42 Stephen Rothwell
  2011-01-31 19:32 ` Pekka Enberg
  0 siblings, 1 reply; 16+ messages in thread
From: Stephen Rothwell @ 2011-01-31  3:42 UTC (permalink / raw)
  To: Pekka Enberg, Christoph Lameter; +Cc: linux-next, linux-kernel, Theodore Tso

[-- Attachment #1: Type: text/plain, Size: 661 bytes --]

Hi all,

After merging the slab tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

fs/ext4/mballoc.c: In function 'ext4_exit_mballoc':
fs/ext4/mballoc.c:2750: error: implicit declaration of function 'kmem_cache_name'
fs/ext4/mballoc.c:2750: warning: cast to pointer from integer of different size

Caused by commit 63310467a3d1ed6a0460ec1f4268126cd1ceec2e ("mm: Remove
support for kmem_cache_name()").  Clearly the last user has not gone, yet.

I have used the version of the slab tree from next-20110121 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: linux-next: build failure after merge of the slab tree
  2011-01-31  3:42 linux-next: build failure after merge of the slab tree Stephen Rothwell
@ 2011-01-31 19:32 ` Pekka Enberg
  2011-02-03 15:19   ` Christoph Lameter
  0 siblings, 1 reply; 16+ messages in thread
From: Pekka Enberg @ 2011-01-31 19:32 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Christoph Lameter, linux-next, linux-kernel, Theodore Tso

On Mon, 2011-01-31 at 14:42 +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the slab tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> fs/ext4/mballoc.c: In function 'ext4_exit_mballoc':
> fs/ext4/mballoc.c:2750: error: implicit declaration of function 'kmem_cache_name'
> fs/ext4/mballoc.c:2750: warning: cast to pointer from integer of different size
> 
> Caused by commit 63310467a3d1ed6a0460ec1f4268126cd1ceec2e ("mm: Remove
> support for kmem_cache_name()").  Clearly the last user has not gone, yet.
> 
> I have used the version of the slab tree from next-20110121 for today.

Christoph, Ted? Should I revert the patch from slab.git?


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: linux-next: build failure after merge of the slab tree
  2011-01-31 19:32 ` Pekka Enberg
@ 2011-02-03 15:19   ` Christoph Lameter
  2011-02-08 15:53     ` Christoph Lameter
  0 siblings, 1 reply; 16+ messages in thread
From: Christoph Lameter @ 2011-02-03 15:19 UTC (permalink / raw)
  To: Pekka Enberg; +Cc: Stephen Rothwell, linux-next, linux-kernel, Theodore Tso

On Mon, 31 Jan 2011, Pekka Enberg wrote:

> On Mon, 2011-01-31 at 14:42 +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the slab tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > fs/ext4/mballoc.c: In function 'ext4_exit_mballoc':
> > fs/ext4/mballoc.c:2750: error: implicit declaration of function 'kmem_cache_name'
> > fs/ext4/mballoc.c:2750: warning: cast to pointer from integer of different size
> >
> > Caused by commit 63310467a3d1ed6a0460ec1f4268126cd1ceec2e ("mm: Remove
> > support for kmem_cache_name()").  Clearly the last user has not gone, yet.
> >
> > I have used the version of the slab tree from next-20110121 for today.
>
> Christoph, Ted? Should I revert the patch from slab.git?

Maybe the ext4 patch is not in -next yet?


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: linux-next: build failure after merge of the slab tree
  2011-02-03 15:19   ` Christoph Lameter
@ 2011-02-08 15:53     ` Christoph Lameter
  2011-02-08 15:55       ` Christoph Lameter
  0 siblings, 1 reply; 16+ messages in thread
From: Christoph Lameter @ 2011-02-08 15:53 UTC (permalink / raw)
  To: Pekka Enberg; +Cc: Stephen Rothwell, linux-next, linux-kernel, Theodore Tso

Here is a patch to fix ext4 (and slab)

Subject: ext4: Remove use of kmem_cache_name

Remove the use of kmem_cache_name from ext4. In order to do that we need to
strdup the name of the cache passed to kmem_cache_create.

Signed-off-by: Christoph Lameter <cl@linux.com>


---
 fs/ext4/mballoc.c |   12 ++----------
 mm/slab.c         |    7 ++++++-
 2 files changed, 8 insertions(+), 11 deletions(-)

Index: linux-2.6/fs/ext4/mballoc.c
===================================================================
--- linux-2.6.orig/fs/ext4/mballoc.c	2011-02-08 09:02:40.000000000 -0600
+++ linux-2.6/fs/ext4/mballoc.c	2011-02-08 09:11:16.000000000 -0600
@@ -2448,15 +2448,10 @@ int ext4_mb_init(struct super_block *sb,
 					bb_counters[sb->s_blocksize_bits + 2]);

 		sprintf(name, "ext4_groupinfo_%d", sb->s_blocksize_bits);
-		namep = kstrdup(name, GFP_KERNEL);
-		if (!namep) {
-			ret = -ENOMEM;
-			goto out;
-		}

 		/* Need to free the kmem_cache_name() when we
 		 * destroy the slab */
-		cachep = kmem_cache_create(namep, len, 0,
+		cachep = kmem_cache_create(name, len, 0,
 					     SLAB_RECLAIM_ACCOUNT, NULL);
 		if (!cachep) {
 			ret = -ENOMEM;
@@ -2746,11 +2741,8 @@ void ext4_exit_mballoc(void)

 	for (i = 0; i < NR_GRPINFO_CACHES; i++) {
 		struct kmem_cache *cachep = ext4_groupinfo_caches[i];
-		if (cachep) {
-			char *name = (char *)kmem_cache_name(cachep);
+		if (cachep)
 			kmem_cache_destroy(cachep);
-			kfree(name);
-		}
 	}
 	ext4_remove_debugfs_entry();
 }
Index: linux-2.6/mm/slab.c
===================================================================
--- linux-2.6.orig/mm/slab.c	2011-02-08 09:06:38.000000000 -0600
+++ linux-2.6/mm/slab.c	2011-02-08 09:09:48.000000000 -0600
@@ -2005,6 +2005,7 @@ static void __kmem_cache_destroy(struct
 			kfree(l3);
 		}
 	}
+	kfree(cachep->name);
 	kmem_cache_free(&cache_cache, cachep);
 }

@@ -2412,7 +2413,11 @@ kmem_cache_create (const char *name, siz
 		BUG_ON(ZERO_OR_NULL_PTR(cachep->slabp_cache));
 	}
 	cachep->ctor = ctor;
-	cachep->name = name;
+	if (slab_is_available())
+		cachep->name = strdup(name);
+	else
+		/* Will never be freed so it does not matter */
+		cachep->name = name;

 	if (setup_cpu_cache(cachep, gfp)) {
 		__kmem_cache_destroy(cachep);

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: linux-next: build failure after merge of the slab tree
  2011-02-08 15:53     ` Christoph Lameter
@ 2011-02-08 15:55       ` Christoph Lameter
  2011-02-08 16:50         ` Ted Ts'o
  2011-02-08 17:11         ` Sedat Dilek
  0 siblings, 2 replies; 16+ messages in thread
From: Christoph Lameter @ 2011-02-08 15:55 UTC (permalink / raw)
  To: Pekka Enberg; +Cc: Stephen Rothwell, linux-next, linux-kernel, Theodore Tso

Argh. I accidentally sent an older version of the patch. This one is the
tested one.


Subject: ext4: Remove use of kmem_cache_name

Remove the use of kmem_cache_name from ext4. In order to do that we need to
strdup the name of the cache passed to kmem_cache_create.

Signed-off-by: Christoph Lameter <cl@linux.com>


---
 fs/ext4/mballoc.c |   12 ++----------
 mm/slab.c         |    7 ++++++-
 2 files changed, 8 insertions(+), 11 deletions(-)

Index: linux-2.6/fs/ext4/mballoc.c
===================================================================
--- linux-2.6.orig/fs/ext4/mballoc.c	2011-02-08 09:02:40.000000000 -0600
+++ linux-2.6/fs/ext4/mballoc.c	2011-02-08 09:11:16.000000000 -0600
@@ -2448,15 +2448,10 @@ int ext4_mb_init(struct super_block *sb,
 					bb_counters[sb->s_blocksize_bits + 2]);

 		sprintf(name, "ext4_groupinfo_%d", sb->s_blocksize_bits);
-		namep = kstrdup(name, GFP_KERNEL);
-		if (!namep) {
-			ret = -ENOMEM;
-			goto out;
-		}

 		/* Need to free the kmem_cache_name() when we
 		 * destroy the slab */
-		cachep = kmem_cache_create(namep, len, 0,
+		cachep = kmem_cache_create(name, len, 0,
 					     SLAB_RECLAIM_ACCOUNT, NULL);
 		if (!cachep) {
 			ret = -ENOMEM;
@@ -2746,11 +2741,8 @@ void ext4_exit_mballoc(void)

 	for (i = 0; i < NR_GRPINFO_CACHES; i++) {
 		struct kmem_cache *cachep = ext4_groupinfo_caches[i];
-		if (cachep) {
-			char *name = (char *)kmem_cache_name(cachep);
+		if (cachep)
 			kmem_cache_destroy(cachep);
-			kfree(name);
-		}
 	}
 	ext4_remove_debugfs_entry();
 }
Index: linux-2.6/mm/slab.c
===================================================================
--- linux-2.6.orig/mm/slab.c	2011-02-08 09:06:38.000000000 -0600
+++ linux-2.6/mm/slab.c	2011-02-08 09:25:39.000000000 -0600
@@ -2005,6 +2005,7 @@ static void __kmem_cache_destroy(struct
 			kfree(l3);
 		}
 	}
+	kfree(cachep->name);
 	kmem_cache_free(&cache_cache, cachep);
 }

@@ -2412,7 +2413,11 @@ kmem_cache_create (const char *name, siz
 		BUG_ON(ZERO_OR_NULL_PTR(cachep->slabp_cache));
 	}
 	cachep->ctor = ctor;
-	cachep->name = name;
+	if (slab_is_available())
+		cachep->name = kstrdup(name, GFP_KERNEL);
+	else
+		/* Will never be freed so it does not matter */
+		cachep->name = name;

 	if (setup_cpu_cache(cachep, gfp)) {
 		__kmem_cache_destroy(cachep);

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: linux-next: build failure after merge of the slab tree
  2011-02-08 15:55       ` Christoph Lameter
@ 2011-02-08 16:50         ` Ted Ts'o
  2011-02-08 17:11         ` Sedat Dilek
  1 sibling, 0 replies; 16+ messages in thread
From: Ted Ts'o @ 2011-02-08 16:50 UTC (permalink / raw)
  To: Christoph Lameter
  Cc: Pekka Enberg, Stephen Rothwell, linux-next, linux-kernel

On Tue, Feb 08, 2011 at 09:55:48AM -0600, Christoph Lameter wrote:
> Argh. I accidentally sent an older version of the patch. This one is the
> tested one.
> 
> Subject: ext4: Remove use of kmem_cache_name
> 
> Remove the use of kmem_cache_name from ext4. In order to do that we need to
> strdup the name of the cache passed to kmem_cache_create.

There is a patch for this that Eric Sandeen has done which I've pushed
to Linus already.

Part of the problem is that some of the slab allocators call strdup,
and some don't.  So the only solution is to pass in a const,
statically allocated name.....

							- Ted

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: linux-next: build failure after merge of the slab tree
  2011-02-08 15:55       ` Christoph Lameter
  2011-02-08 16:50         ` Ted Ts'o
@ 2011-02-08 17:11         ` Sedat Dilek
  2011-02-08 17:44           ` Christoph Lameter
  1 sibling, 1 reply; 16+ messages in thread
From: Sedat Dilek @ 2011-02-08 17:11 UTC (permalink / raw)
  To: Christoph Lameter
  Cc: Pekka Enberg, Stephen Rothwell, linux-next, linux-kernel,
	Theodore Tso, sandeen

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 3835 bytes --]

On Tue, Feb 8, 2011 at 4:55 PM, Christoph Lameter <cl@linux.com> wrote:
> Argh. I accidentally sent an older version of the patch. This one is the
> tested one.
>
>
> Subject: ext4: Remove use of kmem_cache_name
>
> Remove the use of kmem_cache_name from ext4. In order to do that we need to
> strdup the name of the cache passed to kmem_cache_create.
>
> Signed-off-by: Christoph Lameter <cl@linux.com>
>
>
> ---
>  fs/ext4/mballoc.c |   12 ++----------
>  mm/slab.c         |    7 ++++++-
>  2 files changed, 8 insertions(+), 11 deletions(-)
>
> Index: linux-2.6/fs/ext4/mballoc.c
> ===================================================================
> --- linux-2.6.orig/fs/ext4/mballoc.c    2011-02-08 09:02:40.000000000 -0600
> +++ linux-2.6/fs/ext4/mballoc.c 2011-02-08 09:11:16.000000000 -0600
> @@ -2448,15 +2448,10 @@ int ext4_mb_init(struct super_block *sb,
>                                        bb_counters[sb->s_blocksize_bits + 2]);
>
>                sprintf(name, "ext4_groupinfo_%d", sb->s_blocksize_bits);
> -               namep = kstrdup(name, GFP_KERNEL);
> -               if (!namep) {
> -                       ret = -ENOMEM;
> -                       goto out;
> -               }
>
>                /* Need to free the kmem_cache_name() when we
>                 * destroy the slab */
> -               cachep = kmem_cache_create(namep, len, 0,
> +               cachep = kmem_cache_create(name, len, 0,
>                                             SLAB_RECLAIM_ACCOUNT, NULL);
>                if (!cachep) {
>                        ret = -ENOMEM;
> @@ -2746,11 +2741,8 @@ void ext4_exit_mballoc(void)
>
>        for (i = 0; i < NR_GRPINFO_CACHES; i++) {
>                struct kmem_cache *cachep = ext4_groupinfo_caches[i];
> -               if (cachep) {
> -                       char *name = (char *)kmem_cache_name(cachep);
> +               if (cachep)
>                        kmem_cache_destroy(cachep);
> -                       kfree(name);
> -               }
>        }
>        ext4_remove_debugfs_entry();
>  }
> Index: linux-2.6/mm/slab.c
> ===================================================================
> --- linux-2.6.orig/mm/slab.c    2011-02-08 09:06:38.000000000 -0600
> +++ linux-2.6/mm/slab.c 2011-02-08 09:25:39.000000000 -0600
> @@ -2005,6 +2005,7 @@ static void __kmem_cache_destroy(struct
>                        kfree(l3);
>                }
>        }
> +       kfree(cachep->name);
>        kmem_cache_free(&cache_cache, cachep);
>  }
>
> @@ -2412,7 +2413,11 @@ kmem_cache_create (const char *name, siz
>                BUG_ON(ZERO_OR_NULL_PTR(cachep->slabp_cache));
>        }
>        cachep->ctor = ctor;
> -       cachep->name = name;
> +       if (slab_is_available())
> +               cachep->name = kstrdup(name, GFP_KERNEL);
> +       else
> +               /* Will never be freed so it does not matter */
> +               cachep->name = name;
>
>        if (setup_cpu_cache(cachep, gfp)) {
>                __kmem_cache_destroy(cachep);
>

Isn't the fs/ext4 part obsolete by Eric's "ext4: make grpinfo slab
cache names static"?
The mentionned patch is pending in ext4.git#{master, for_linus} [1].

Shouldn't this patch reduced to the mm/slab part?

- Sedat -


[1] http://git.kernel.org/?p=linux/kernel/git/tytso/ext4.git;a=commit;h=11510460562fb3fa1b061ed4d7350ccdc39a984f
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: linux-next: build failure after merge of the slab tree
  2011-02-08 17:11         ` Sedat Dilek
@ 2011-02-08 17:44           ` Christoph Lameter
  0 siblings, 0 replies; 16+ messages in thread
From: Christoph Lameter @ 2011-02-08 17:44 UTC (permalink / raw)
  To: Sedat Dilek
  Cc: Pekka Enberg, Stephen Rothwell, linux-next, linux-kernel,
	Theodore Tso, sandeen

On Tue, 8 Feb 2011, Sedat Dilek wrote:

> Isn't the fs/ext4 part obsolete by Eric's "ext4: make grpinfo slab
> cache names static"?
> The mentionned patch is pending in ext4.git#{master, for_linus} [1].
>
> Shouldn't this patch reduced to the mm/slab part?

If Eric fixed it with string constants then we do not need the slab part
either.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: linux-next: build failure after merge of the slab tree
  2013-07-10 18:48   ` Christoph Lameter
@ 2013-07-11  6:42     ` Pekka Enberg
  0 siblings, 0 replies; 16+ messages in thread
From: Pekka Enberg @ 2013-07-11  6:42 UTC (permalink / raw)
  To: Christoph Lameter; +Cc: Stephen Rothwell, linux-next, linux-kernel

On Wed, 10 Jul 2013, Pekka Enberg wrote:
>> Yes, it indeed interacts badly with kmemleak and tracing. I reverted the
>> commit.

On 07/10/2013 09:48 PM, Christoph Lameter wrote:
> 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"...

Can you please resend these after the merge window closes?

			Pekka

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: linux-next: build failure after merge of the slab tree
  2013-07-10  7:00 ` Pekka Enberg
@ 2013-07-10 18:48   ` Christoph Lameter
  2013-07-11  6:42     ` Pekka Enberg
  0 siblings, 1 reply; 16+ messages in thread
From: Christoph Lameter @ 2013-07-10 18:48 UTC (permalink / raw)
  To: Pekka Enberg; +Cc: Stephen Rothwell, linux-next, linux-kernel

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@linux.com>

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;
 /*

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: linux-next: build failure after merge of the slab tree
  2013-07-10  2:56 Stephen Rothwell
@ 2013-07-10  7:00 ` Pekka Enberg
  2013-07-10 18:48   ` Christoph Lameter
  0 siblings, 1 reply; 16+ messages in thread
From: Pekka Enberg @ 2013-07-10  7:00 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Christoph Lameter, linux-next, linux-kernel

On 07/10/2013 05:56 AM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the slab tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from include/linux/slab.h:17:0,
>                   from include/linux/crypto.h:24,
>                   from arch/x86/kernel/asm-offsets.c:8:
> include/linux/kmemleak.h: In function 'kmemleak_alloc_recursive':
> include/linux/kmemleak.h:44:16: error: 'SLAB_NOLEAKTRACE' undeclared (first use in this function)
>    if (!(flags & SLAB_NOLEAKTRACE))
>                  ^
> include/linux/kmemleak.h: In function 'kmemleak_free_recursive':
> include/linux/kmemleak.h:50:16: error: 'SLAB_NOLEAKTRACE' undeclared (first use in this function)
>    if (!(flags & SLAB_NOLEAKTRACE))
>                  ^
>
> Probably caused by commit 590a63973e36 ("mm/sl[aou]b: Move kmalloc
> definitions to slab.h").
>
> I have used the slab tree from next-20130709 for today.
>
> And, yes, I am a little annoyed by this.

Yes, it indeed interacts badly with kmemleak and tracing. I reverted the 
commit.

			Pekka


^ permalink raw reply	[flat|nested] 16+ messages in thread

* linux-next: build failure after merge of the slab tree
@ 2013-07-10  2:56 Stephen Rothwell
  2013-07-10  7:00 ` Pekka Enberg
  0 siblings, 1 reply; 16+ messages in thread
From: Stephen Rothwell @ 2013-07-10  2:56 UTC (permalink / raw)
  To: Pekka Enberg, Christoph Lameter; +Cc: linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 977 bytes --]

Hi all,

After merging the slab tree, today's linux-next build (x86_64
allmodconfig) failed like this:

In file included from include/linux/slab.h:17:0,
                 from include/linux/crypto.h:24,
                 from arch/x86/kernel/asm-offsets.c:8:
include/linux/kmemleak.h: In function 'kmemleak_alloc_recursive':
include/linux/kmemleak.h:44:16: error: 'SLAB_NOLEAKTRACE' undeclared (first use in this function)
  if (!(flags & SLAB_NOLEAKTRACE))
                ^
include/linux/kmemleak.h: In function 'kmemleak_free_recursive':
include/linux/kmemleak.h:50:16: error: 'SLAB_NOLEAKTRACE' undeclared (first use in this function)
  if (!(flags & SLAB_NOLEAKTRACE))
                ^

Probably caused by commit 590a63973e36 ("mm/sl[aou]b: Move kmalloc
definitions to slab.h").

I have used the slab tree from next-20130709 for today.

And, yes, I am a little annoyed by this.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: linux-next: build failure after merge of the slab tree
  2010-12-09  3:03 Stephen Rothwell
@ 2010-12-09 16:25 ` Pekka Enberg
  0 siblings, 0 replies; 16+ messages in thread
From: Pekka Enberg @ 2010-12-09 16:25 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Christoph Lameter, linux-next, linux-kernel, Steven Rostedt,
	Richard Kennedy

On Thu, 2010-12-09 at 14:03 +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the slab tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> lib/built-in.o: In function `.zlib_inflate_blob':
> (.text+0x8640): undefined reference to `.kmem_cache_alloc_notrace'
> 
> This build failure went away when I removed the lib directory from the
> object tree and rebuilt.  So I guess we have an unexpressed dependency.

Did your config change from SLAB to SLUB or something?
lib/zlib_inflate/infutil.c includes <linux/slab.h> but if your config
changes, I'm guessing it doesn't work all that well if you change the
allocator because those tracing functions are in <linux/sl{a,u}b_def.h>.

			Pekka


^ permalink raw reply	[flat|nested] 16+ messages in thread

* linux-next: build failure after merge of the slab tree
@ 2010-12-09  3:03 Stephen Rothwell
  2010-12-09 16:25 ` Pekka Enberg
  0 siblings, 1 reply; 16+ messages in thread
From: Stephen Rothwell @ 2010-12-09  3:03 UTC (permalink / raw)
  To: Pekka Enberg, Christoph Lameter
  Cc: linux-next, linux-kernel, Steven Rostedt, Richard Kennedy

[-- Attachment #1: Type: text/plain, Size: 486 bytes --]

Hi all,

After merging the slab tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

lib/built-in.o: In function `.zlib_inflate_blob':
(.text+0x8640): undefined reference to `.kmem_cache_alloc_notrace'

This build failure went away when I removed the lib directory from the
object tree and rebuilt.  So I guess we have an unexpressed dependency.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: linux-next: build failure after merge of the slab tree
  2010-10-27  0:33 Stephen Rothwell
@ 2010-10-27  7:29 ` Pekka Enberg
  0 siblings, 0 replies; 16+ messages in thread
From: Pekka Enberg @ 2010-10-27  7:29 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Pekka Enberg, Christoph Lameter, linux-next, linux-kernel

On Wed, Oct 27, 2010 at 3:33 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> After merging the slab tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> gcc: /scratch/sfr/next/Documentation/vm/slabinfo.c: No such file or directory
> gcc: no input files
>
> Caused by commit f5ac4916e9840292edd33c7a52b10364526547f3 ("slub: move
> slabinfo.c to tools/slub/slabinfo.c").  Missing update to
> Documentation/vm/Makefile?

Oh, we have one of those. Sorry about the breakage, I'll fix it up later today.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* linux-next: build failure after merge of the slab tree
@ 2010-10-27  0:33 Stephen Rothwell
  2010-10-27  7:29 ` Pekka Enberg
  0 siblings, 1 reply; 16+ messages in thread
From: Stephen Rothwell @ 2010-10-27  0:33 UTC (permalink / raw)
  To: Pekka Enberg, Christoph Lameter; +Cc: linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 536 bytes --]

Hi all,

After merging the slab tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

gcc: /scratch/sfr/next/Documentation/vm/slabinfo.c: No such file or directory
gcc: no input files

Caused by commit f5ac4916e9840292edd33c7a52b10364526547f3 ("slub: move
slabinfo.c to tools/slub/slabinfo.c").  Missing update to
Documentation/vm/Makefile?

I have used the slab tree from next-20101026 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2013-07-11  6:42 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-01-31  3:42 linux-next: build failure after merge of the slab tree Stephen Rothwell
2011-01-31 19:32 ` Pekka Enberg
2011-02-03 15:19   ` Christoph Lameter
2011-02-08 15:53     ` Christoph Lameter
2011-02-08 15:55       ` Christoph Lameter
2011-02-08 16:50         ` Ted Ts'o
2011-02-08 17:11         ` Sedat Dilek
2011-02-08 17:44           ` Christoph Lameter
  -- strict thread matches above, loose matches on Subject: below --
2013-07-10  2:56 Stephen Rothwell
2013-07-10  7:00 ` Pekka Enberg
2013-07-10 18:48   ` Christoph Lameter
2013-07-11  6:42     ` Pekka Enberg
2010-12-09  3:03 Stephen Rothwell
2010-12-09 16:25 ` Pekka Enberg
2010-10-27  0:33 Stephen Rothwell
2010-10-27  7:29 ` Pekka Enberg

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).