slab:Fix the unexpected index mapping result of kmalloc_size(INDEX_NODE + 1)

slab:Fix the unexpected index mapping result of kmalloc_size(INDEX_NODE + 1)

[liu.hailong6]

From e7749a94d63dae21feaa53953c8affeb23050d04 Mon Sep 17 00:00:00 2001
From: liuhailong <liu.hailong6@zte.com.cn>
Date: Thu, 9 Jul 2015 09:02:27 +0800
Subject: [PATCH] slab:Fix the unexpected index mapping result of 
kmalloc_size(INDEX_NODE + 1)

Kernel after v3.9 using kmalloc_size(INDEX_NODE + 1) to get the next 
larger
cache size than the size index INDEX_NODE mapping, instead of
malloc_sizes[INDEX_L3 + 1].cs_size which realized in the kernel 3.9.
However, sometimes we can't get the right output we expected by
kmalloc_size(INDEX_NODE + 1),and ,this may cause some BUGs.

The mapping table in latest kernel likes:
    index = {0,   1,  2 ,  3,  4,   5,   6,     n}
     size = {0,   96, 192, 8, 16， 32，  64， 2^n}
The mapping table before 3.10 likes this:
    index = {0 , 1 , 2,   3,  4 ,  5 ,  6,   n}
    size  = {32, 64, 96, 128, 192, 256, 512, 2^(n+3)}

The problem described as following on my mips64 machine:
  (1)When configured DEBUG_SLAB && DEBUG_PAGEALLOC && DEBUG_LOCK_ALLOC
&& DEBUG_SPINLOCK, the sizeof(struct kmem_cache_node) will be "150", and
the macro INDEX_NODE turns out to be "2":
#define INDEX_NODE kmalloc_index(sizeof(struct kmem_cache_node))
  (2)Then the result of kmalloc_size(INDEX_NODE + 1) is 8.
  (3)Then "if(size >= kmalloc_size(INDEX_NODE + 1)" will lead to "size
= PAGE_SIZE".
  (4)Then "if ((size >= (PAGE_SIZE >> 3))" test will be satisfied and
"flags |= CFLGS_OFF_SLAB" will be covered.
  (5)"if (flags & CFLGS_OFF_SLAB)" test will be satisfied and will go
to "cachep->slabp_cache = kmalloc_slab(slab_size, 0u)", and the result
here may be NULL while kernel bootup.
  (6)Finally,"BUG_ON(ZERO_OR_NULL_PTR(cachep->slabp_cache));" cause the
BUG info as the following shows(may be only mips64 has this problem):

 #20
task: ffffffffc072cdc0 ti: ffffffffc06b4000 task.ti: ffffffffc06b4000
$ 0   : 0000000000000000 0000000000000018 0000000000000001 
0000000100000fff
$ 4   : 0000000000000030 0000000000000000 0000000000001004 
0000000000001000
$ 8   : ffffffff80002800 000000000000000b 0000000000000000 
0000000000000000
$12   : 0000000080000000 0000000000000000 c0000000bf818ebc 
c0000000bf818eb8
$16   : c0000000bf818ea0 0000000080002800 0000000000000000 
0000000000001000
$20   : 0000000000000034 0000000080000000 0000000000000000 
0000000000000006
$24   : ffffffffc1160000 00000000000003f4
$28   : ffffffffc06b4000 ffffffffc06b7d40 0000000000002000 
ffffffffc01d077c
Hi    : 0000000000000fff
Lo    : 0000000000100000
epc   : ffffffffc01d0784 __kmem_cache_create+0x2ac/0x530
    Not tainted
ra    : ffffffffc01d077c __kmem_cache_create+0x2a4/0x530
Status: 141000e2        KX SX UX KERNEL EXL
Cause : 40808034
PrId  : 000c1300 (Broadcom XLPII)
Process swapper (pid: 0, threadinfo=ffffffffc06b4000, task=ffffffffc072cdc
        0,tls=0000000000000000)
*HwTLS: fffffffffadebeef
Stack : 00000000c073b018 c0000000bf818ea0 0000000000000040 
0000000000000000
        ffffffffc115b360 ffffffffc115b360 0000000000000017 
0000000000000007
        0000000000000006 ffffffffc0780f54 0000000000002000 
0000000000000040
        c0000000bf818ea0 0000000000000000 0000000000000040 
ffffffffc0780fec
        0000000000002000 c0000000bf810fc0 ffffffffc115b390 
0000000000000006
        ffffffffc1160000 ffffffffc07810b0 0000000000000001 
c0000000bf809000
        ffffffffc0a30000 ffffffffc07a0000 ffffffffc07a1758 
ffffffffc0a30000
        ffffffff8c190000 ffffffff8bd02983 0000000000000000 
ffffffff8c18f798
        0000000000000000 ffffffffc07746e0 ffffffffc07a1758 
0000000000000000
        0000000000000000 ffffffff805c5580 0000000000000000 
0000000000000000
          ...
Call Trace:
[<ffffffffc01d0784>] __kmem_cache_create+0x2ac/0x530
[<ffffffffc0780f54>] create_boot_cache+0x54/0x90
[<ffffffffc0780fec>] create_kmalloc_cache+0x5c/0x94
[<ffffffffc07810b0>] create_kmalloc_caches+0x8c/0x1b0
[<ffffffffc07746e0>] start_kernel+0x1a0/0x408

This patch can fix the problem of kmalloc_size(INDEX_NODE + 1)and will
remove the BUG above, I test it on my mips64 mechine.

Signed-off-by: Liuhailong <liu.hailong6@zte.com.cn>
Reviewed-by: Jianxuexin <jiang.xuexin@zte.com.cn>

---
 mm/slab.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/mm/slab.c b/mm/slab.c
index 68b95a8..f1d33d9 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -2204,7 +2204,7 @@ __kmem_cache_create (struct kmem_cache *cachep, 
unsigned long flags)
                        size += BYTES_PER_WORD;
        }
 #if FORCED_DEBUG && defined(CONFIG_DEBUG_PAGEALLOC)
-       if (size >= kmalloc_size(INDEX_NODE + 1)
+       if (size >= kmalloc_size(INDEX_NODE)*2
            && cachep->object_size > cache_line_size()
            && ALIGN(size, cachep->align) < PAGE_SIZE) {
                cachep->obj_offset += PAGE_SIZE - ALIGN(size, 
cachep->align);
-- 
1.7.1
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

Re: slab:Fix the unexpected index mapping result of kmalloc_size(INDEX_NODE + 1)

[Andrew Morton]

That patch is a bit of a mess.  Below is a cleaned up version.

It appears that the regression you've identified was caused by

commit e33660165c901d18e7d3df2290db070d3e4b46df
Author: Christoph Lameter <cl@linux.com>
Date:   Thu Jan 10 19:14:18 2013 +0000

    slab: Use common kmalloc_index/kmalloc_size functions


Reviewers sought, please.



From: Liuhailong <liu.hailong6@zte.com.cn>
Subject: slab: fix unexpected index mapping result of kmalloc_size(INDEX_NODE + 1)

Kernels after v3.9 use kmalloc_size(INDEX_NODE + 1) to get the next larger
cache size than the size index INDEX_NODE mapping.  In kernels 3.9 and
earlier we used malloc_sizes[INDEX_L3 + 1].cs_size.

However, sometimes we can't get the right output we expected via
kmalloc_size(INDEX_NODE + 1), causing a BUG().

The mapping table in the latest kernel is like:
    index = {0,   1,  2 ,  3,  4,   5,   6,   n}
     size = {0,   96, 192, 8, 16,  32,  64,   2^n}
The mapping table before 3.10 is like this:
    index = {0 , 1 , 2,   3,  4 ,  5 ,  6,   n}
    size  = {32, 64, 96, 128, 192, 256, 512, 2^(n+3)}

The problem on my mips64 machine is as follows:

(1) When configured DEBUG_SLAB && DEBUG_PAGEALLOC && DEBUG_LOCK_ALLOC
    && DEBUG_SPINLOCK, the sizeof(struct kmem_cache_node) will be "150",
    and the macro INDEX_NODE turns out to be "2": #define INDEX_NODE
    kmalloc_index(sizeof(struct kmem_cache_node))

(2) Then the result of kmalloc_size(INDEX_NODE + 1) is 8.

(3) Then "if(size >= kmalloc_size(INDEX_NODE + 1)" will lead to "size
    = PAGE_SIZE".

(4) Then "if ((size >= (PAGE_SIZE >> 3))" test will be satisfied and
    "flags |= CFLGS_OFF_SLAB" will be covered.

(5) if (flags & CFLGS_OFF_SLAB)" test will be satisfied and will go to
    "cachep->slabp_cache = kmalloc_slab(slab_size, 0u)", and the result
    here may be NULL while kernel bootup.

(6) Finally,"BUG_ON(ZERO_OR_NULL_PTR(cachep->slabp_cache));" causes the
    BUG info as the following shows (may be only mips64 has this problem):

 #20
task: ffffffffc072cdc0 ti: ffffffffc06b4000 task.ti: ffffffffc06b4000
$ 0   : 0000000000000000 0000000000000018 0000000000000001 0000000100000fff
$ 4   : 0000000000000030 0000000000000000 0000000000001004 0000000000001000
$ 8   : ffffffff80002800 000000000000000b 0000000000000000 0000000000000000
$12   : 0000000080000000 0000000000000000 c0000000bf818ebc c0000000bf818eb8
$16   : c0000000bf818ea0 0000000080002800 0000000000000000 0000000000001000
$20   : 0000000000000034 0000000080000000 0000000000000000 0000000000000006
$24   : ffffffffc1160000 00000000000003f4
$28   : ffffffffc06b4000 ffffffffc06b7d40 0000000000002000 ffffffffc01d077c
Hi    : 0000000000000fff
Lo    : 0000000000100000
epc   : ffffffffc01d0784 __kmem_cache_create+0x2ac/0x530
    Not tainted
ra    : ffffffffc01d077c __kmem_cache_create+0x2a4/0x530
Status: 141000e2        KX SX UX KERNEL EXL
Cause : 40808034
PrId  : 000c1300 (Broadcom XLPII)
Process swapper (pid: 0, threadinfo=ffffffffc06b4000, task=ffffffffc072cdc
        0,tls=0000000000000000)
*HwTLS: fffffffffadebeef
Stack : 00000000c073b018 c0000000bf818ea0 0000000000000040 0000000000000000
        ffffffffc115b360 ffffffffc115b360 0000000000000017 0000000000000007
        0000000000000006 ffffffffc0780f54 0000000000002000 0000000000000040
        c0000000bf818ea0 0000000000000000 0000000000000040 ffffffffc0780fec
        0000000000002000 c0000000bf810fc0 ffffffffc115b390 0000000000000006
        ffffffffc1160000 ffffffffc07810b0 0000000000000001 c0000000bf809000
        ffffffffc0a30000 ffffffffc07a0000 ffffffffc07a1758 ffffffffc0a30000
        ffffffff8c190000 ffffffff8bd02983 0000000000000000 ffffffff8c18f798
        0000000000000000 ffffffffc07746e0 ffffffffc07a1758 0000000000000000
        0000000000000000 ffffffff805c5580 0000000000000000 0000000000000000
          ...
Call Trace:
[<ffffffffc01d0784>] __kmem_cache_create+0x2ac/0x530
[<ffffffffc0780f54>] create_boot_cache+0x54/0x90
[<ffffffffc0780fec>] create_kmalloc_cache+0x5c/0x94
[<ffffffffc07810b0>] create_kmalloc_caches+0x8c/0x1b0
[<ffffffffc07746e0>] start_kernel+0x1a0/0x408

This patch fixes the problem of kmalloc_size(INDEX_NODE + 1) removes the
BUG.  I tested it on my mips64 mechine.

Signed-off-by: Liuhailong <liu.hailong6@zte.com.cn>
Reviewed-by: Jianxuexin <jiang.xuexin@zte.com.cn>
Cc: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 mm/slab.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff -puN mm/slab.c~slab-fix-the-unexpected-index-mapping-result-of-kmalloc_sizeindex_node-1 mm/slab.c
--- a/mm/slab.c~slab-fix-the-unexpected-index-mapping-result-of-kmalloc_sizeindex_node-1
+++ a/mm/slab.c
@@ -2190,7 +2190,7 @@ __kmem_cache_create (struct kmem_cache *
 			size += BYTES_PER_WORD;
 	}
 #if FORCED_DEBUG && defined(CONFIG_DEBUG_PAGEALLOC)
-	if (size >= kmalloc_size(INDEX_NODE + 1)
+	if (size >= kmalloc_size(INDEX_NODE) * 2
 	    && cachep->object_size > cache_line_size()
 	    && ALIGN(size, cachep->align) < PAGE_SIZE) {
 		cachep->obj_offset += PAGE_SIZE - ALIGN(size, cachep->align);
_

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: slab:Fix the unexpected index mapping result of kmalloc_size(INDEX_NODE + 1)

[Christoph Lameter]

On Wed, 29 Jul 2015, Andrew Morton wrote:

> From: Liuhailong <liu.hailong6@zte.com.cn>
> Subject: slab: fix unexpected index mapping result of kmalloc_size(INDEX_NODE + 1)

Well its a clean fix. Does the intended check in a better way.

Acked-by: Christoph Lameter

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: slab:Fix the unexpected index mapping result of kmalloc_size(INDEX_NODE + 1)

[Joonsoo Kim]

On Wed, Jul 29, 2015 at 03:28:03PM -0700, Andrew Morton wrote:
> 
> That patch is a bit of a mess.  Below is a cleaned up version.
> 
> It appears that the regression you've identified was caused by
> 
> commit e33660165c901d18e7d3df2290db070d3e4b46df
> Author: Christoph Lameter <cl@linux.com>
> Date:   Thu Jan 10 19:14:18 2013 +0000
> 
>     slab: Use common kmalloc_index/kmalloc_size functions
> 
> 
> Reviewers sought, please.
> 
> 
> 
> From: Liuhailong <liu.hailong6@zte.com.cn>
> Subject: slab: fix unexpected index mapping result of kmalloc_size(INDEX_NODE + 1)
> 
> Kernels after v3.9 use kmalloc_size(INDEX_NODE + 1) to get the next larger
> cache size than the size index INDEX_NODE mapping.  In kernels 3.9 and
> earlier we used malloc_sizes[INDEX_L3 + 1].cs_size.
> 
> However, sometimes we can't get the right output we expected via
> kmalloc_size(INDEX_NODE + 1), causing a BUG().
> 
> The mapping table in the latest kernel is like:
>     index = {0,   1,  2 ,  3,  4,   5,   6,   n}
>      size = {0,   96, 192, 8, 16,  32,  64,   2^n}
> The mapping table before 3.10 is like this:
>     index = {0 , 1 , 2,   3,  4 ,  5 ,  6,   n}
>     size  = {32, 64, 96, 128, 192, 256, 512, 2^(n+3)}
> 
> The problem on my mips64 machine is as follows:
> 
> (1) When configured DEBUG_SLAB && DEBUG_PAGEALLOC && DEBUG_LOCK_ALLOC
>     && DEBUG_SPINLOCK, the sizeof(struct kmem_cache_node) will be "150",
>     and the macro INDEX_NODE turns out to be "2": #define INDEX_NODE
>     kmalloc_index(sizeof(struct kmem_cache_node))
> 
> (2) Then the result of kmalloc_size(INDEX_NODE + 1) is 8.
> 
> (3) Then "if(size >= kmalloc_size(INDEX_NODE + 1)" will lead to "size
>     = PAGE_SIZE".
> 
> (4) Then "if ((size >= (PAGE_SIZE >> 3))" test will be satisfied and
>     "flags |= CFLGS_OFF_SLAB" will be covered.
> 
> (5) if (flags & CFLGS_OFF_SLAB)" test will be satisfied and will go to
>     "cachep->slabp_cache = kmalloc_slab(slab_size, 0u)", and the result
>     here may be NULL while kernel bootup.
> 
> (6) Finally,"BUG_ON(ZERO_OR_NULL_PTR(cachep->slabp_cache));" causes the
>     BUG info as the following shows (may be only mips64 has this problem):
> 
>  #20
> task: ffffffffc072cdc0 ti: ffffffffc06b4000 task.ti: ffffffffc06b4000
> $ 0   : 0000000000000000 0000000000000018 0000000000000001 0000000100000fff
> $ 4   : 0000000000000030 0000000000000000 0000000000001004 0000000000001000
> $ 8   : ffffffff80002800 000000000000000b 0000000000000000 0000000000000000
> $12   : 0000000080000000 0000000000000000 c0000000bf818ebc c0000000bf818eb8
> $16   : c0000000bf818ea0 0000000080002800 0000000000000000 0000000000001000
> $20   : 0000000000000034 0000000080000000 0000000000000000 0000000000000006
> $24   : ffffffffc1160000 00000000000003f4
> $28   : ffffffffc06b4000 ffffffffc06b7d40 0000000000002000 ffffffffc01d077c
> Hi    : 0000000000000fff
> Lo    : 0000000000100000
> epc   : ffffffffc01d0784 __kmem_cache_create+0x2ac/0x530
>     Not tainted
> ra    : ffffffffc01d077c __kmem_cache_create+0x2a4/0x530
> Status: 141000e2        KX SX UX KERNEL EXL
> Cause : 40808034
> PrId  : 000c1300 (Broadcom XLPII)
> Process swapper (pid: 0, threadinfo=ffffffffc06b4000, task=ffffffffc072cdc
>         0,tls=0000000000000000)
> *HwTLS: fffffffffadebeef
> Stack : 00000000c073b018 c0000000bf818ea0 0000000000000040 0000000000000000
>         ffffffffc115b360 ffffffffc115b360 0000000000000017 0000000000000007
>         0000000000000006 ffffffffc0780f54 0000000000002000 0000000000000040
>         c0000000bf818ea0 0000000000000000 0000000000000040 ffffffffc0780fec
>         0000000000002000 c0000000bf810fc0 ffffffffc115b390 0000000000000006
>         ffffffffc1160000 ffffffffc07810b0 0000000000000001 c0000000bf809000
>         ffffffffc0a30000 ffffffffc07a0000 ffffffffc07a1758 ffffffffc0a30000
>         ffffffff8c190000 ffffffff8bd02983 0000000000000000 ffffffff8c18f798
>         0000000000000000 ffffffffc07746e0 ffffffffc07a1758 0000000000000000
>         0000000000000000 ffffffff805c5580 0000000000000000 0000000000000000
>           ...
> Call Trace:
> [<ffffffffc01d0784>] __kmem_cache_create+0x2ac/0x530
> [<ffffffffc0780f54>] create_boot_cache+0x54/0x90
> [<ffffffffc0780fec>] create_kmalloc_cache+0x5c/0x94
> [<ffffffffc07810b0>] create_kmalloc_caches+0x8c/0x1b0
> [<ffffffffc07746e0>] start_kernel+0x1a0/0x408
> 
> This patch fixes the problem of kmalloc_size(INDEX_NODE + 1) removes the
> BUG.  I tested it on my mips64 mechine.
> 
> Signed-off-by: Liuhailong <liu.hailong6@zte.com.cn>
> Reviewed-by: Jianxuexin <jiang.xuexin@zte.com.cn>
> Cc: Christoph Lameter <cl@linux.com>
> Cc: Pekka Enberg <penberg@kernel.org>
> Cc: David Rientjes <rientjes@google.com>
> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
> 
>  mm/slab.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff -puN mm/slab.c~slab-fix-the-unexpected-index-mapping-result-of-kmalloc_sizeindex_node-1 mm/slab.c
> --- a/mm/slab.c~slab-fix-the-unexpected-index-mapping-result-of-kmalloc_sizeindex_node-1
> +++ a/mm/slab.c
> @@ -2190,7 +2190,7 @@ __kmem_cache_create (struct kmem_cache *
>  			size += BYTES_PER_WORD;
>  	}
>  #if FORCED_DEBUG && defined(CONFIG_DEBUG_PAGEALLOC)
> -	if (size >= kmalloc_size(INDEX_NODE + 1)
> +	if (size >= kmalloc_size(INDEX_NODE) * 2
>  	    && cachep->object_size > cache_line_size()
>  	    && ALIGN(size, cachep->align) < PAGE_SIZE) {
>  		cachep->obj_offset += PAGE_SIZE - ALIGN(size, cachep->align);

Hello,

I don't think that this fix is right.
Just "kmalloc_size(INDEX_NODE) * 2" looks insane because it means 192 * 2
= 384 on his platform. Why we need to check size is larger than 384?

I'm wondering what's the meaning of this check "size >=
kmalloc_size(INDEX_NODE + 1)".

Requirement for activating debug_pagealloc may be off-slab freelist
management. It can be possible after some of kmalloc cache is enabled
for off-slab freelist management, so what we need to check here is
somethinkg like following.

-       if (size >= kmalloc_size(INDEX_NODE + 1)
+       if (!slab_early_init &&
+               size >= XXX

In fact, we can activate debug_pagealloc for more less sized
kmem_cache. Perhaps, size >= 64 is okay, too. But, it increases
memory usage greatly so we need pre-determined value here.
Before Christoph's commit e498be7daf in 2005, it is set to 128. So,
I think that 128 or 256 is good choice here.

Thanks.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: slab:Fix the unexpected index mapping result of kmalloc_size(INDEX_NODE + 1)

[Christoph Lameter]

On Fri, 31 Jul 2015, Joonsoo Kim wrote:

> I don't think that this fix is right.
> Just "kmalloc_size(INDEX_NODE) * 2" looks insane because it means 192 * 2
> = 384 on his platform. Why we need to check size is larger than 384?

Its an arbitrary boundary. Making it large ensures that the smaller caches
stay operational and do not fall back to page sized allocations.

> I'm wondering what's the meaning of this check "size >=
> kmalloc_size(INDEX_NODE + 1)".

This is pretty old code. IMHO The check is if it fits in the
kmem_cache used for INDEX_NODE. If not then fall back to a page sized
allocation for the cache. Looks like DEBUG_PAGEALLOC wants one page per
object.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: slab:Fix the unexpected index mapping result of kmalloc_size(INDEX_NODE + 1)

[Joonsoo Kim]

On Fri, Jul 31, 2015 at 08:57:35AM -0500, Christoph Lameter wrote:
> On Fri, 31 Jul 2015, Joonsoo Kim wrote:
> 
> > I don't think that this fix is right.
> > Just "kmalloc_size(INDEX_NODE) * 2" looks insane because it means 192 * 2
> > = 384 on his platform. Why we need to check size is larger than 384?
> 
> Its an arbitrary boundary. Making it large ensures that the smaller caches
> stay operational and do not fall back to page sized allocations.

If it is an arbitrary boundary, it would be better to use static value
such as "256" rather than kmalloc_size(INDEX_NODE) * 2.
Value of kmalloc_size(INDEX_NODE) * 2 can be different in some archs
and it is difficult to manage such variation. It would cause this kinds of
bug again. I recommand following change. How about it?

-       if (size >= kmalloc_size(INDEX_NODE + 1)
+       if (!slab_early_init &&
+               size >= kmalloc_size(INDEX_NODE) &&
+               size >= 256

Thanks.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: slab:Fix the unexpected index mapping result of kmalloc_size(INDEX_NODE + 1)

[Andrew Morton]

On Fri, 7 Aug 2015 10:56:09 +0900 Joonsoo Kim <iamjoonsoo.kim@lge.com> wrote:

> On Fri, Jul 31, 2015 at 08:57:35AM -0500, Christoph Lameter wrote:
> > On Fri, 31 Jul 2015, Joonsoo Kim wrote:
> > 
> > > I don't think that this fix is right.
> > > Just "kmalloc_size(INDEX_NODE) * 2" looks insane because it means 192 * 2
> > > = 384 on his platform. Why we need to check size is larger than 384?
> > 
> > Its an arbitrary boundary. Making it large ensures that the smaller caches
> > stay operational and do not fall back to page sized allocations.
> 
> If it is an arbitrary boundary, it would be better to use static value
> such as "256" rather than kmalloc_size(INDEX_NODE) * 2.
> Value of kmalloc_size(INDEX_NODE) * 2 can be different in some archs
> and it is difficult to manage such variation. It would cause this kinds of
> bug again. I recommand following change. How about it?
> 
> -       if (size >= kmalloc_size(INDEX_NODE + 1)
> +       if (!slab_early_init &&
> +               size >= kmalloc_size(INDEX_NODE) &&
> +               size >= 256
> 

Guys, can we please finish this off?  afaict Jianxuexin's original
patch is considered undesirable, but his machine is still going BUG.


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: slab:Fix the unexpected index mapping result of kmalloc_size(INDEX_NODE + 1)

[Joonsoo Kim]

On Fri, Sep 04, 2015 at 01:29:02PM -0700, Andrew Morton wrote:
> On Fri, 7 Aug 2015 10:56:09 +0900 Joonsoo Kim <iamjoonsoo.kim@lge.com> wrote:
> 
> > On Fri, Jul 31, 2015 at 08:57:35AM -0500, Christoph Lameter wrote:
> > > On Fri, 31 Jul 2015, Joonsoo Kim wrote:
> > > 
> > > > I don't think that this fix is right.
> > > > Just "kmalloc_size(INDEX_NODE) * 2" looks insane because it means 192 * 2
> > > > = 384 on his platform. Why we need to check size is larger than 384?
> > > 
> > > Its an arbitrary boundary. Making it large ensures that the smaller caches
> > > stay operational and do not fall back to page sized allocations.
> > 
> > If it is an arbitrary boundary, it would be better to use static value
> > such as "256" rather than kmalloc_size(INDEX_NODE) * 2.
> > Value of kmalloc_size(INDEX_NODE) * 2 can be different in some archs
> > and it is difficult to manage such variation. It would cause this kinds of
> > bug again. I recommand following change. How about it?
> > 
> > -       if (size >= kmalloc_size(INDEX_NODE + 1)
> > +       if (!slab_early_init &&
> > +               size >= kmalloc_size(INDEX_NODE) &&
> > +               size >= 256
> > 
> 
> Guys, can we please finish this off?  afaict Jianxuexin's original
> patch is considered undesirable, but his machine is still going BUG.

Hello,

Sure. It should be fixed soon. If Christoph agree with my approach, I
will make it to proper formatted patch.

Thanks.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: slab:Fix the unexpected index mapping result of kmalloc_size(INDEX_NODE + 1)

[Christoph Lameter]

On Mon, 7 Sep 2015, Joonsoo Kim wrote:

> Sure. It should be fixed soon. If Christoph agree with my approach, I
> will make it to proper formatted patch.

Could you explain that approach again?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: slab:Fix the unexpected index mapping result of kmalloc_size(INDEX_NODE + 1)

[Joonsoo Kim]

2015-09-09 2:49 GMT+09:00 Christoph Lameter <cl@linux.com>:
> On Mon, 7 Sep 2015, Joonsoo Kim wrote:
>
>> Sure. It should be fixed soon. If Christoph agree with my approach, I
>> will make it to proper formatted patch.
>
> Could you explain that approach again?

Instead of following hunk,
-       if (size >= kmalloc_size(INDEX_NODE + 1)
+       if (size >= kmalloc_size(INDEX_NODE) * 2 &&

Using this hunk.
-       if (size >= kmalloc_size(INDEX_NODE + 1)
+       if (!slab_early_init &&
+               size >= kmalloc_size(INDEX_NODE) &&
+               size >= 256 &&

What this codes intend for is to determine whether this slab
can be debugged by debug_pagealloc. It become possible
when off slab management is possible so this condition is to
check whether off slab management is possible or not. Off slab
management requires small sized slab so we should not allow
debug_pagealloc until proper sized slab is initialized.
Initialization sequence is like:

The mapping table in the latest kernel is like:
    index = {0,   1,  2 ,  3,  4,   5,   6,   n}
     size = {0,   96, 192, 8, 16,  32,  64,   2^n}

So, when we initialize 96, 192 or 8, proper slab isn't initialized.
If we allow debug_pagealloc larger than 256 sized slab,
small sized slab would be already initialized so no error
happens. I think it is better than
kmalloc_size(INDEX_NODE) * 2, because that doesn't
guarantee size is larger than 192.

Thanks.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: slab:Fix the unexpected index mapping result of kmalloc_size(INDEX_NODE + 1)

[Christoph Lameter]

On Fri, 11 Sep 2015, Joonsoo Kim wrote:

> So, when we initialize 96, 192 or 8, proper slab isn't initialized.
> If we allow debug_pagealloc larger than 256 sized slab,
> small sized slab would be already initialized so no error
> happens. I think it is better than
> kmalloc_size(INDEX_NODE) * 2, because that doesn't
> guarantee size is larger than 192.

Sounds good. Please send a patch.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

slab:Fix the unexpected index mapping result of kmalloc_size(INDEX_NODE + 1)

[liu.hailong6]

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

From e7749a94d63dae21feaa53953c8affeb23050d04 Mon Sep 17 00:00:00 2001
From: liuhailong <liu.hailong6@zte.com.cn>
Date: Thu, 9 Jul 2015 09:02:27 +0800
Subject: [PATCH] slab:Fix the unexpected index mapping result of 
kmalloc_size(INDEX_NODE + 1)

Kernel after v3.9 using kmalloc_size(INDEX_NODE + 1) to get the next 
larger
cache size than the size index INDEX_NODE mapping, instead of
malloc_sizes[INDEX_L3 + 1].cs_size which realized in the kernel 3.9.
However, sometimes we can't get the right output we expected by
kmalloc_size(INDEX_NODE + 1),and ,this may cause some BUGs.

The mapping table in latest kernel likes:
    index = {0,   1,  2 ,  3,  4,   5,   6,     n}
     size = {0,   96, 192, 8, 16， 32，  64， 2^n}
The mapping table before 3.10 likes this:
    index = {0 , 1 , 2,   3,  4 ,  5 ,  6,   n}
    size  = {32, 64, 96, 128, 192, 256, 512, 2^(n+3)}

The problem discribed as following on my mips64 machine:
  (1)When configured DEBUG_SLAB && DEBUG_PAGEALLOC && DEBUG_LOCK_ALLOC
&& DEBUG_SPINLOCK, the sizeof(struct kmem_cache_node) will be "150", and
the macro INDEX_NODE turns out to be "2":
#define INDEX_NODE kmalloc_index(sizeof(struct kmem_cache_node))
  (2)Then the result of kmalloc_size(INDEX_NODE + 1) is 8.
  (3)Then "if(size >= kmalloc_size(INDEX_NODE + 1)" will lead to "size
= PAGE_SIZE".
  (4)Then "if ((size >= (PAGE_SIZE >> 3))" test will be satisfied and
"flags |= CFLGS_OFF_SLAB" will be excuted.
  (5)"if (flags & CFLGS_OFF_SLAB)" test will be satisfied and will go
to "cachep->slabp_cache = kmalloc_slab(slab_size, 0u)", and the result
here may be NULL while kernel bootup.
  (6)Finally,"BUG_ON(ZERO_OR_NULL_PTR(cachep->slabp_cache));" cause the
BUG info as the following shows(may be only mips64 has this problem):

 #20
task: ffffffffc072cdc0 ti: ffffffffc06b4000 task.ti: ffffffffc06b4000
$ 0   : 0000000000000000 0000000000000018 0000000000000001 
0000000100000fff
$ 4   : 0000000000000030 0000000000000000 0000000000001004 
0000000000001000
$ 8   : ffffffff80002800 000000000000000b 0000000000000000 
0000000000000000
$12   : 0000000080000000 0000000000000000 c0000000bf818ebc 
c0000000bf818eb8
$16   : c0000000bf818ea0 0000000080002800 0000000000000000 
0000000000001000
$20   : 0000000000000034 0000000080000000 0000000000000000 
0000000000000006
$24   : ffffffffc1160000 00000000000003f4
$28   : ffffffffc06b4000 ffffffffc06b7d40 0000000000002000 
ffffffffc01d077c
Hi    : 0000000000000fff
Lo    : 0000000000100000
epc   : ffffffffc01d0784 __kmem_cache_create+0x2ac/0x530
    Not tainted
ra    : ffffffffc01d077c __kmem_cache_create+0x2a4/0x530
Status: 141000e2        KX SX UX KERNEL EXL
Cause : 40808034
PrId  : 000c1300 (Broadcom XLPII)
Process swapper (pid: 0, threadinfo=ffffffffc06b4000, task=ffffffffc072cdc
        0,tls=0000000000000000)
*HwTLS: fffffffffadebeef
Stack : 00000000c073b018 c0000000bf818ea0 0000000000000040 
0000000000000000
        ffffffffc115b360 ffffffffc115b360 0000000000000017 
0000000000000007
        0000000000000006 ffffffffc0780f54 0000000000002000 
0000000000000040
        c0000000bf818ea0 0000000000000000 0000000000000040 
ffffffffc0780fec
        0000000000002000 c0000000bf810fc0 ffffffffc115b390 
0000000000000006
        ffffffffc1160000 ffffffffc07810b0 0000000000000001 
c0000000bf809000
        ffffffffc0a30000 ffffffffc07a0000 ffffffffc07a1758 
ffffffffc0a30000
        ffffffff8c190000 ffffffff8bd02983 0000000000000000 
ffffffff8c18f798
        0000000000000000 ffffffffc07746e0 ffffffffc07a1758 
0000000000000000
        0000000000000000 ffffffff805c5580 0000000000000000 
0000000000000000
          ...
Call Trace:
[<ffffffffc01d0784>] __kmem_cache_create+0x2ac/0x530
[<ffffffffc0780f54>] create_boot_cache+0x54/0x90
[<ffffffffc0780fec>] create_kmalloc_cache+0x5c/0x94
[<ffffffffc07810b0>] create_kmalloc_caches+0x8c/0x1b0
[<ffffffffc07746e0>] start_kernel+0x1a0/0x408

This patch can fix the problem of kmalloc_size(INDEX_NODE + 1)and will
remove the BUG above, I test it on my mips64 mechine.

Signed-off-by: Liuhailong <liu.hailong6@zte.com.cn>
Reviewed-by: Jiangxuexin <jiang.xuexin@zte.com.cn>

---
 mm/slab.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/mm/slab.c b/mm/slab.c
index 68b95a8..f1d33d9 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -2204,7 +2204,7 @@ __kmem_cache_create (struct kmem_cache *cachep, 
unsigned long flags)
                        size += BYTES_PER_WORD;
        }
 #if FORCED_DEBUG && defined(CONFIG_DEBUG_PAGEALLOC)
-       if (size >= kmalloc_size(kmalloc_next_index(INDEX_NODE))
+       if (size >= kmalloc_size(INDEX_NODE)*2
            && cachep->object_size > cache_line_size()
            && ALIGN(size, cachep->align) < PAGE_SIZE) {
                cachep->obj_offset += PAGE_SIZE - ALIGN(size, 
cachep->align);
-- 
1.7.1

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.
N‹§²æìr¸›zǧu©ž²Æ {\b­†éì¹»\x1c®&Þ–)îÆi¢žØ^n‡r¶‰šŽŠÝ¢j$½§$¢¸\x05¢¹¨­è§~Š'.)îÄÃ,yèm¶ŸÿÃ\f%Š{±šj+ƒðèž×¦j)Z†·Ÿ