[Bug 1475204] Re: Fix kmalloc slab creation sequence

Ubuntu 14.10 (Utopic Unicorn) with kernel 3.16 has reached end of life
and this bug will not be fixed for that specific release. Please file a
new bug if this issue still exists in a supported release.

** Changed in: linux (Ubuntu Trusty)
Status: Fix Committed => Won't Fix

** Changed in: linux (Ubuntu Utopic)
Status: Fix Committed => Won't Fix

--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/1475204

Title:
Fix kmalloc slab creation sequence

Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Trusty:
Won't Fix
Status in linux source package in Utopic:
Won't Fix
Status in linux source package in Vivid:
Fix Released

Bug description:
[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@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@linux-foundation.org: s/kmalloc_names/kmalloc_info/, tweak comment text]
    Signed-off-by: Gavin Guo <gavin.guo@canonical.com>
    Acked-by: 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>
    Signed-off-by: Linus Torvalds <torvalds@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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1475204/+subscriptions