[Trusty/Utopic/Vivid][SRU][PATCH] LP#1475204 -- Fix kmalloc slab creation sequence

[Gavin Guo]

BugLink: http://bugs.launchpad.net/bugs/1475204

[Impact]

commit 4066c33d0308f8 breaks booting under KVM
https://lkml.org/lkml/2015/6/26/341

I can no longer boot Linus's tree under KVM using a 32-bit i386 build;
it just hangs before any messages get sent to the serial console.

This following commit breaks 32-bit and 64-bit x86 if you have
CONFIG_SLAB enabled. When I switched to CONFIG_SLUB, the kernel
boots. So it appears this commit is breaking kernel configurations
with CONFIG_SLAB enabled.

It bisects down to:

commit 4066c33d0308f87e9a3b0c7fafb9141c0bfbfa77
Author: Gavin Guo <gavin.guo at canonical.com>
Date: Wed Jun 24 16:55:54 2015 -0700

    mm/slab_common: support the slub_debug boot option on specific object size

    The slub_debug=PU,kmalloc-xx cannot work because in the
    create_kmalloc_caches() the s->name is created after the
    create_kmalloc_cache() is called. The name is NULL in the
    create_kmalloc_cache() so the kmem_cache_flags() would not set the
    slub_debug flags to the s->flags. The fix here set up a kmalloc_names
    string array for the initialization purpose and delete the dynamic name
    creation of kmalloc_caches.

    [akpm at linux-foundation.org: s/kmalloc_names/kmalloc_info/, tweak comment text]
    Signed-off-by: Gavin Guo <gavin.guo at canonical.com>
    Acked-by: Christoph Lameter <cl at linux.com>
    Cc: Pekka Enberg <penberg at kernel.org>
    Cc: David Rientjes <rientjes at google.com>
    Cc: Joonsoo Kim <iamjoonsoo.kim at lge.com>
    Signed-off-by: Andrew Morton <akpm at linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds at linux-foundation.org>

[Fix]

This is the regression of bug:
BugLink: http://bugs.launchpad.net/bugs/1456952

and fixed by:
[PATCH] Fix kmalloc slab creation sequence
https://lkml.org/lkml/2015/6/29/231

This patch restores the slab creation sequence that was broken by
commit 4066c33d0308f8 and also reverts the portions that introduced
the KMALLOC_LOOP_XXX macros. Those can never really work since the
slab creation is much more complex than just going from a minimum to
a maximum number.

The latest upstream kernel boots cleanly on my machine with a 64 bit
x86 configuration under KVM using either SLAB or SLUB.

[Test cases]

Currently, the bug can't be reproduced on the Ubuntu kernel by
enabling the slab allocator with i386 and x86_64 architecture.
However, in case anyone will hit the bug, the patch should be applied
in the Ubuntu kernel.

[Regression potential]

The patch is to fix the kmalloc_caches initialization sequence, that
the 96, and 192 bytes kmem_cache should be enabled after the normal
2's exponential size kmem_cache. This should have low regression
potential.

Christoph Lameter (1):
  Fix kmalloc slab creation sequence

 include/linux/slab.h | 22 ----------------------
 mm/slab_common.c     | 33 +++++++++++++++++----------------
 2 files changed, 17 insertions(+), 38 deletions(-)

-- 
2.0.0