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

[Chris J Arges]

This commit is in v4.2, so I'm not sure if its worth also applying to wily/4.1
until we rebase to 4.2.

Other than that the patches for T/U/V are an ACK as an SRU pending the
development version is OK.

--chris

On Mon, Jul 20, 2015 at 09:16:47PM +0800, Gavin Guo wrote:
> 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
> 
> 
> -- 
> kernel-team mailing list
> kernel-team at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team
>