kernel-packages team mailing list archive

[Gavin Guo <gavin.guo@xxxxxxxxxxxxx>]

** Description changed:

  [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@xxxxxxxxxxxxx>
  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@xxxxxxxxxxxxxxxxxxxx: s/kmalloc_names/kmalloc_info/, tweak comment text]
      Signed-off-by: Gavin Guo <gavin.guo@xxxxxxxxxxxxx>
      Acked-by: Christoph Lameter <cl@xxxxxxxxx>
      Cc: Pekka Enberg <penberg@xxxxxxxxxx>
      Cc: David Rientjes <rientjes@xxxxxxxxxx>
      Cc: Joonsoo Kim <iamjoonsoo.kim@xxxxxxx>
      Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
      Signed-off-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
  
  [Fix]
  
  [PATCH] Fix kmalloc slab creation sequence
  https://lkml.org/lkml/2015/6/29/231
  
- 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 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.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1475204

Title:
  Fix kmalloc slab creation sequence

Status in linux package in Ubuntu:
  Incomplete

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@xxxxxxxxxxxxx>
  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@xxxxxxxxxxxxxxxxxxxx: s/kmalloc_names/kmalloc_info/, tweak comment text]
      Signed-off-by: Gavin Guo <gavin.guo@xxxxxxxxxxxxx>
      Acked-by: Christoph Lameter <cl@xxxxxxxxx>
      Cc: Pekka Enberg <penberg@xxxxxxxxxx>
      Cc: David Rientjes <rientjes@xxxxxxxxxx>
      Cc: Joonsoo Kim <iamjoonsoo.kim@xxxxxxx>
      Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
      Signed-off-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>

  [Fix]

  [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