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

[liu.hailong6@zte.com.cn]

[-- 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†·Ÿ