linux-next: build failure after merge of the slab tree

linux-next: build failure after merge of the slab tree

[Stephen Rothwell]

[-- 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 --]

Re: linux-next: build failure after merge of the slab tree

[Pekka Enberg]

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

Re: linux-next: build failure after merge of the slab tree

[Christoph Lameter]

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

Re: linux-next: build failure after merge of the slab tree

[Pekka Enberg]

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

Re: linux-next: build failure after merge of the slab tree

[Vlastimil Babka]

On 11/25/22 02:49, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the slab tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> mm/slub.c:965:13: error: 'freelist_corrupted' defined but not used [-Werror=unused-function]
>   965 | static bool freelist_corrupted(struct kmem_cache *s, struct slab *slab,
>       |             ^~~~~~~~~~~~~~~~~~
> 
> Caused by commit
> 
>   f6e94ad44e77 ("mm, slub: remove percpu slabs with CONFIG_SLUB_TINY")
> 
> I have used the slab tree from next-20221123 again.

I tried the allmodconfig and:

WARNING: unmet direct dependencies detected for SLUB_DEBUG
  Depends on [n]: SLUB [=y] && SYSFS [=y] && !SLUB_TINY [=y]
  Selected by [y]:
  - KASAN_GENERIC [=y] && <choice> && HAVE_ARCH_KASAN [=y] && CC_HAS_KASAN_GENERIC [=y] && CC_HAS_WORKING_NOSANITIZE_ADDRESS [=y] && SLUB [=y]

Wasn't aware it's possible that it will leave a combination of configs
that's not allowed and just warn about it. Oh well.

I'll solve it by:
--- a/lib/Kconfig.kasan
+++ b/lib/Kconfig.kasan
@@ -37,7 +37,7 @@ menuconfig KASAN
                     (HAVE_ARCH_KASAN_SW_TAGS && CC_HAS_KASAN_SW_TAGS)) && \
                    CC_HAS_WORKING_NOSANITIZE_ADDRESS) || \
                   HAVE_ARCH_KASAN_HW_TAGS
-       depends on (SLUB && SYSFS) || (SLAB && !DEBUG_SLAB)
+       depends on (SLUB && SYSFS && !SLUB_TINY) || (SLAB && !DEBUG_SLAB)
        select STACKDEPOT_ALWAYS_INIT
        help
          Enables KASAN (Kernel Address Sanitizer) - a dynamic memory safety

linux-next: build failure after merge of the slab tree

[Stephen Rothwell]

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

Hi all,

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

mm/slub.c:965:13: error: 'freelist_corrupted' defined but not used [-Werror=unused-function]
  965 | static bool freelist_corrupted(struct kmem_cache *s, struct slab *slab,
      |             ^~~~~~~~~~~~~~~~~~

Caused by commit

  f6e94ad44e77 ("mm, slub: remove percpu slabs with CONFIG_SLUB_TINY")

I have used the slab tree from next-20221123 again.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the slab tree

[Vlastimil Babka]

On 11/24/22 05:39, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the slab tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:

Oops, thanks, looks like I had !CONFIG_PRINTK when testing that... Will be
fixed in the next slab-next.

> mm/slab_common.c: In function 'kmem_dump_obj':
> mm/slab_common.c:603:49: error: 'struct kmem_cache' has no member named 'usersize'
>   603 |         if (kp.kp_slab_cache && kp.kp_slab_cache->usersize)
>       |                                                 ^~
> In file included from include/asm-generic/bug.h:22,
>                  from arch/powerpc/include/asm/bug.h:159,
>                  from include/linux/bug.h:5,
>                  from include/linux/thread_info.h:13,
>                  from include/asm-generic/preempt.h:5,
>                  from ./arch/powerpc/include/generated/asm/preempt.h:1,
>                  from include/linux/preempt.h:78,
>                  from include/linux/spinlock.h:56,
>                  from include/linux/mmzone.h:8,
>                  from include/linux/gfp.h:7,
>                  from include/linux/slab.h:15,
>                  from mm/slab_common.c:7:
> mm/slab_common.c:604:53: error: 'struct kmem_cache' has no member named 'usersize'
>   604 |                 pr_cont(" size %u", kp.kp_slab_cache->usersize);
>       |                                                     ^~
> include/linux/printk.h:429:33: note: in definition of macro 'printk_index_wrap'
>   429 |                 _p_func(_fmt, ##__VA_ARGS__);                           \
>       |                                 ^~~~~~~~~~~
> include/linux/printk.h:542:9: note: in expansion of macro 'printk'
>   542 |         printk(KERN_CONT fmt, ##__VA_ARGS__)
>       |         ^~~~~~
> mm/slab_common.c:604:17: note: in expansion of macro 'pr_cont'
>   604 |                 pr_cont(" size %u", kp.kp_slab_cache->usersize);
>       |                 ^~~~~~~
> 
> Caused by commit
> 
>   3cdb7b6ad16a ("mm, slab: ignore hardened usercopy parameters when disabled")
> 
> I have used the slab tree from next-20221123 for today.
> 

linux-next: build failure after merge of the slab tree

[Stephen Rothwell]

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

Hi all,

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

mm/slab_common.c: In function 'kmem_dump_obj':
mm/slab_common.c:603:49: error: 'struct kmem_cache' has no member named 'usersize'
  603 |         if (kp.kp_slab_cache && kp.kp_slab_cache->usersize)
      |                                                 ^~
In file included from include/asm-generic/bug.h:22,
                 from arch/powerpc/include/asm/bug.h:159,
                 from include/linux/bug.h:5,
                 from include/linux/thread_info.h:13,
                 from include/asm-generic/preempt.h:5,
                 from ./arch/powerpc/include/generated/asm/preempt.h:1,
                 from include/linux/preempt.h:78,
                 from include/linux/spinlock.h:56,
                 from include/linux/mmzone.h:8,
                 from include/linux/gfp.h:7,
                 from include/linux/slab.h:15,
                 from mm/slab_common.c:7:
mm/slab_common.c:604:53: error: 'struct kmem_cache' has no member named 'usersize'
  604 |                 pr_cont(" size %u", kp.kp_slab_cache->usersize);
      |                                                     ^~
include/linux/printk.h:429:33: note: in definition of macro 'printk_index_wrap'
  429 |                 _p_func(_fmt, ##__VA_ARGS__);                           \
      |                                 ^~~~~~~~~~~
include/linux/printk.h:542:9: note: in expansion of macro 'printk'
  542 |         printk(KERN_CONT fmt, ##__VA_ARGS__)
      |         ^~~~~~
mm/slab_common.c:604:17: note: in expansion of macro 'pr_cont'
  604 |                 pr_cont(" size %u", kp.kp_slab_cache->usersize);
      |                 ^~~~~~~

Caused by commit

  3cdb7b6ad16a ("mm, slab: ignore hardened usercopy parameters when disabled")

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

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the slab tree

[Stephen Rothwell]

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

Hi all,

On Tue, 6 Sep 2022 20:05:44 -0700 Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
>
> On Tue, Sep 6, 2022 at 11:37 AM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
> >
> > On Tue, Sep 6, 2022 at 12:53 AM Vlastimil Babka <vbabka@suse.cz> wrote:  
> > >
> > > On 9/6/22 08:51, Stephen Rothwell wrote:  
> > > > Hi all,  
> > >
> > > Hi,
> > >  
> > > > After merging the slab tree, today's linux-next build (powerpc
> > > > ppc64_defconfig) failed like this:
> > > >
> > > > kernel/bpf/memalloc.c: In function 'bpf_mem_free':
> > > > kernel/bpf/memalloc.c:613:33: error: implicit declaration of function '__ksize'; did you mean 'ksize'? [-Werror=implicit-function-declaration]
> > > >    613 |         idx = bpf_mem_cache_idx(__ksize(ptr - LLIST_NODE_SZ));
> > > >        |                                 ^~~~~~~
> > > >        |                                 ksize  
> > >
> > > Could you use ksize() here? I'm guessing you picked __ksize() because
> > > kasan_unpoison_element() in mm/mempool.c did, but that's to avoid
> > > kasan_unpoison_range() in ksize() as this caller does it differently.
> > > AFAICS your function doesn't handle kasan differently, so ksize() should
> > > be fine.  
> >
> > Ok. Will change to use ksize().  
> 
> Just pushed the following commit to address the issue:
> https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=1e660f7ebe0ff6ac65ee0000280392d878630a67
> 
> It will get to net-next soon.

I replaced my revert with that patch for today (and will discard that
when it arrives via some other tree).

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the slab tree

[Vlastimil Babka]

On 9/7/22 05:05, Alexei Starovoitov wrote:
> On Tue, Sep 6, 2022 at 11:37 AM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
>>
>> On Tue, Sep 6, 2022 at 12:53 AM Vlastimil Babka <vbabka@suse.cz> wrote:
>> >
>> > On 9/6/22 08:51, Stephen Rothwell wrote:
>> > > Hi all,
>> >
>> > Hi,
>> >
>> > > After merging the slab tree, today's linux-next build (powerpc
>> > > ppc64_defconfig) failed like this:
>> > >
>> > > kernel/bpf/memalloc.c: In function 'bpf_mem_free':
>> > > kernel/bpf/memalloc.c:613:33: error: implicit declaration of function '__ksize'; did you mean 'ksize'? [-Werror=implicit-function-declaration]
>> > >    613 |         idx = bpf_mem_cache_idx(__ksize(ptr - LLIST_NODE_SZ));
>> > >        |                                 ^~~~~~~
>> > >        |                                 ksize
>> >
>> > Could you use ksize() here? I'm guessing you picked __ksize() because
>> > kasan_unpoison_element() in mm/mempool.c did, but that's to avoid
>> > kasan_unpoison_range() in ksize() as this caller does it differently.
>> > AFAICS your function doesn't handle kasan differently, so ksize() should
>> > be fine.
>>
>> Ok. Will change to use ksize().
> 
> Just pushed the following commit to address the issue:
> https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=1e660f7ebe0ff6ac65ee0000280392d878630a67
> 
> It will get to net-next soon.

Thanks!

Re: linux-next: build failure after merge of the slab tree

[Alexei Starovoitov]

On Tue, Sep 6, 2022 at 11:37 AM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Tue, Sep 6, 2022 at 12:53 AM Vlastimil Babka <vbabka@suse.cz> wrote:
> >
> > On 9/6/22 08:51, Stephen Rothwell wrote:
> > > Hi all,
> >
> > Hi,
> >
> > > After merging the slab tree, today's linux-next build (powerpc
> > > ppc64_defconfig) failed like this:
> > >
> > > kernel/bpf/memalloc.c: In function 'bpf_mem_free':
> > > kernel/bpf/memalloc.c:613:33: error: implicit declaration of function '__ksize'; did you mean 'ksize'? [-Werror=implicit-function-declaration]
> > >    613 |         idx = bpf_mem_cache_idx(__ksize(ptr - LLIST_NODE_SZ));
> > >        |                                 ^~~~~~~
> > >        |                                 ksize
> >
> > Could you use ksize() here? I'm guessing you picked __ksize() because
> > kasan_unpoison_element() in mm/mempool.c did, but that's to avoid
> > kasan_unpoison_range() in ksize() as this caller does it differently.
> > AFAICS your function doesn't handle kasan differently, so ksize() should
> > be fine.
>
> Ok. Will change to use ksize().

Just pushed the following commit to address the issue:
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=1e660f7ebe0ff6ac65ee0000280392d878630a67

It will get to net-next soon.

Re: linux-next: build failure after merge of the slab tree

[Alexei Starovoitov]

On Tue, Sep 6, 2022 at 12:53 AM Vlastimil Babka <vbabka@suse.cz> wrote:
>
> On 9/6/22 08:51, Stephen Rothwell wrote:
> > Hi all,
>
> Hi,
>
> > After merging the slab tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > kernel/bpf/memalloc.c: In function 'bpf_mem_free':
> > kernel/bpf/memalloc.c:613:33: error: implicit declaration of function '__ksize'; did you mean 'ksize'? [-Werror=implicit-function-declaration]
> >    613 |         idx = bpf_mem_cache_idx(__ksize(ptr - LLIST_NODE_SZ));
> >        |                                 ^~~~~~~
> >        |                                 ksize
>
> Could you use ksize() here? I'm guessing you picked __ksize() because
> kasan_unpoison_element() in mm/mempool.c did, but that's to avoid
> kasan_unpoison_range() in ksize() as this caller does it differently.
> AFAICS your function doesn't handle kasan differently, so ksize() should
> be fine.

Ok. Will change to use ksize().

Re: linux-next: build failure after merge of the slab tree

[Vlastimil Babka]

On 9/6/22 08:51, Stephen Rothwell wrote:
> Hi all,

Hi,

> After merging the slab tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> kernel/bpf/memalloc.c: In function 'bpf_mem_free':
> kernel/bpf/memalloc.c:613:33: error: implicit declaration of function '__ksize'; did you mean 'ksize'? [-Werror=implicit-function-declaration]
>    613 |         idx = bpf_mem_cache_idx(__ksize(ptr - LLIST_NODE_SZ));
>        |                                 ^~~~~~~
>        |                                 ksize

Could you use ksize() here? I'm guessing you picked __ksize() because 
kasan_unpoison_element() in mm/mempool.c did, but that's to avoid 
kasan_unpoison_range() in ksize() as this caller does it differently.
AFAICS your function doesn't handle kasan differently, so ksize() should 
be fine.

> Caused by commit
> 
>    8dfa9d554061 ("mm/slab_common: move declaration of __ksize() to mm/slab.h")
> 
> interacting with commit
> 
>    7c8199e24fa0 ("bpf: Introduce any context BPF specific memory allocator.")
> 
> from the bpf-next tree.
> 
> I have reverted the slab tree commit for today.
> 

linux-next: build failure after merge of the slab tree

[Stephen Rothwell]

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

Hi all,

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

kernel/bpf/memalloc.c: In function 'bpf_mem_free':
kernel/bpf/memalloc.c:613:33: error: implicit declaration of function '__ksize'; did you mean 'ksize'? [-Werror=implicit-function-declaration]
  613 |         idx = bpf_mem_cache_idx(__ksize(ptr - LLIST_NODE_SZ));
      |                                 ^~~~~~~
      |                                 ksize

Caused by commit

  8dfa9d554061 ("mm/slab_common: move declaration of __ksize() to mm/slab.h")

interacting with commit

  7c8199e24fa0 ("bpf: Introduce any context BPF specific memory allocator.")

from the bpf-next tree.

I have reverted the slab tree commit for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: build failure after merge of the slab tree

[Christoph Lameter]

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.

Re: linux-next: build failure after merge of the slab tree

[Sedat Dilek]

[-- 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¥

Re: linux-next: build failure after merge of the slab tree

[Sedat Dilek]

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

Re: linux-next: build failure after merge of the slab tree

[Ted Ts'o]

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

Re: linux-next: build failure after merge of the slab tree

[Christoph Lameter]

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);

Re: linux-next: build failure after merge of the slab tree

[Christoph Lameter]

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);

Re: linux-next: build failure after merge of the slab tree

[Christoph Lameter]

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?

Re: linux-next: build failure after merge of the slab tree

[Pekka Enberg]

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?

linux-next: build failure after merge of the slab tree

[Stephen Rothwell]

[-- 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 --]

Re: linux-next: build failure after merge of the slab tree

[Pekka Enberg]

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

linux-next: build failure after merge of the slab tree

[Stephen Rothwell]

[-- 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 --]

Re: linux-next: build failure after merge of the slab tree

[Pekka Enberg]

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.

linux-next: build failure after merge of the slab tree

[Stephen Rothwell]

[-- 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 --]